The HL7 version 3 data type task group has had its twentieth conference call on Monday, March 8, 1999, 2:00 PM EST to 2:30 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.3.2 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.
Klaus Veil suggests to rename "MAIDEN" to "UNMARRIED" name. We will do that. The table of name part types now reads as shown below.
Irma now wondered what use the maiden name is for. Because we have spouse name, birth name, adoption name, chosen name, why is the unmarried (maiden) name still necessary. The answer is: (1) because people beleave they need it (i.o.w. we don't want to discuss this all over again), and (2) because in many cases all you know is that someone has a "maiden" name, but you don't usually know whether this was acquired through birth, adoption, or deedpoll.
| 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. |
| unmarried | U | A name that a person (either sex) had immediately before her/his first marriage. Usually called "maiden name", 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 maiden name should specify the last family name a person acquired before giving it up again through marriage. |
| 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 | M | The name assumed
from the partner in a marital relationship (hence the
"M"). 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. |
| Axis 4 Additional lassifiers for affixes. Usually only one value allowed per affix. Classification does not try to be complete. | ||
| voorvoegsel | VV | A dutch "voorveugsel" is something like "van" or "de" that might have indicated noblety in the past but no longer so. Similar prefixes exist in other languages such es Spanish, French or Portugese. |
| academic | AT | Indicate that a prefix like "Dr." or a suffix like "MD" or "PhD" is an academic title. |
| professional | PT | Primarily in the British Imperial culture people tend to have an abbreviation of their professional organization as part of their credential suffices. |
| noblety | NT | In Europe there are still people with noblety titles. German "von" is generally a noblety title, not a mere voorveugsel. Others are "Earl of" or "His Majesty King of ..." etc. Rarely used nowadays, but some systems do keep track of this. |
Since we did not have a chance to talk about this I just added what I believe should more than suffice for academic titles, professional credentials, voorveugsels and noblety titles on axis 4. You can qualify both a suffix and a prefix as an academic title, which keeps track of the problem that "PhD" and "MD" are suffixes but Dr. and "Prof. Dr. med. Dr. phil. h.c." are prefixes.
We understand that more than one classifier of Axis 2 is allowed for each name part. Such as:
"Dorothea" {G} "Schadow" {FM} "geb." {P} "Riemer" {FBU}for my wife.
If we can't come up with name variant purpose codes, we should not define that component. It seems noone really has an idea of name variant purpose code. So, we will probably erase it from our definition. Unless, or until, someone comes up with some of those codes.
There are two related use cases, though, which we should follow up on.
Dawid Rowed has an action item to investigate how this problem is tackled by Australian public health care workers. The changes we would have to make to support this linking of name part variant to an organization are rather heavy. So we want to make sure we understand what the people who need this really want.
Since Joann brought this use case up last time, Joann and other Kaiser folks will find out on how they deal with this problem at Kaiser internally. Again, we don't want to beat people over the head with stuff that nobody wants to use.
Seems like we need much less flexibility and power with organization names. We considered what might be to organization names:
Different name parts, such as "Hewlett-Packard" vs. "HP" vs. "Inc.", "Co.", "Ltd.", "B.V.", "AG", "GmbH", etc.
"Marriage" of companies and trading of divisions, thus, UNIX was a trade mark of AT&T, then USL, then Novell, and who knows. "Daimler" and "Crysler" are now "Daimler-Crysler" and "Behring", a manufacturer of vaccines, is known or subsumed by some other name in the U.S.
Anyway, we concluded that noone really keeps track of those things, so all we need is an organization name string and, perhaps, a name type code. HL7 v2.3 had a name type code table for organization names (XON) including:
Display name has no defined use, since names are always displayed and it begs the question "whose display?". I wonder whether anyone in healthcare would want to include the Wall Street ticker symbol or the Indianapolis Star newspaper's abbreviation of a manufacturer of vaccines. But there is no reason why we should restrict this existing "feature" of version 2.3.
Further discussion was about whether we would make a mistake to drop everything but the first two components from HL7 v2.3's XON type. But we could be assured of Mark Shafarman's wisdom, who, though not part of this call, in his earlier drafts of v3 data types did just that.
All in all this did not seem like a very controversial or important issue. So, unless there is any significant objection we can just declare closure with a v2.3-like solution.
| Organization Name (ON) | |||
|---|---|---|---|
| A collection of organization name variants. | |||
| SET OF Organization Name Variant |
| Organization Name Variant | |||
|---|---|---|---|
| This type is not used outside of the Organization Name data type. Organization Names are regarded as a collection of organization name variants each used in different contexts or for a different purpose. | |||
| component name | type/domain | optionality | description |
| type | Code Value | optional | A type code indicates what an organization name is to be used for. Examples are: alias, legal, stock-exchange. |
| value | Character String | mandatory | This contains the actual name data as a simple character string. |
Irma had some comments on Addresses. Where to put things like "3rd floor", or "opposite to house number 27" (as it occurs in Amsterdam's House-Boats.)
Several options were discussed. Generally, it is not necessary to classify each and every part of an address. So, one can add all kinds of stuff in an address without haveing to make up a classifier for it. Thus I once send a letter to an old fried of mine who lived in a village near of my old home town:
To Gerhard HeuselThe letter was sent from Thailand and it actually arrived at the destination I intended. Our address data type allows just this level of painless flexibility which obviously is of great values for rural home health care workers.
son of [at that time I knew the first name of his father])
main road right behind the big curve on the left side,
Kusterdingen near Tuebingen.
GERMANY
The house boat locator "opposite to 27" could be covered by the "HNR" (house number) address component. As long as Dutch systems do not cover "opposite to" as a separate component from house number, this should work.
The "3rd floor" is a locator between house and appratment number. As Robin Zimmerman reports, the Universal Postal Union subsumes "3rd floor", "Appt. 324", and "Suite 1023" under "unit designator". So, we will redefine the "APT" address part type to "UNT" for "unit".
:-)| Short | Long | Meaning |
|---|---|---|
L | LIT | literal this is the default role code |
K | DEL | delimiter stuff, printed without framing whitespace. Line break if no value component provided. |
C | CNT | country |
T | CTY | city (town) |
E | STA | state
("E" as in French état, which should
reconcile the French who have to use "E" for their
"departements") |
Z | ZIP | ZIP code |
H | HNR | house number (aka. "primary street number", however, it is not the number of the street, but the number of the house or lot alongside the street.) |
U | UNT | unit designator, such as appartment number, suite number, but also floor. There may be several unit designators in an address to cover things like: "3rd floor, Appt. 342" |
S | STR | street name or number |
ST | STT | street type (e.g. street, avenue, road, lane, ...) (probably not useful enough) |
D | DIR | direction (e.g., N, S, W, E) |
| ... | ||
Next conference call is next Monday, March 15, 1999, 4:00 PM EST.
The time will be this way, because we will have Irma joining in later (10 PM her time) so Klaus and Dawid can get on at a more reasonable time (i.e. 8 instead of 6 AM their time).
Agenda items are:
This will be the final call on those PAFM related issues. We will collect "homeworks" and discuss about the name variant purpose code. There will be no further call on this issue, so please make sure you get your "foot into the door". Raise your concerns and come with proposals. Anything that can not be resolved by next week must wait for a "penalty period" since we can not afford to get bogged down by this.
regards
-Gunther Schadow