# EntityNameParts **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2005-03-09 09:29 UTC **Views:** 1 **Replies:** 66 **URL:** https://discourse.openehr.org/t/entitynameparts/14480 --- ## Post #1 by @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 --- ## Post #2 by @Isabel_Roman 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 --- ## Post #3 by @USM_Bish1 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 --- ## Post #4 by @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 --- ## Post #5 by @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 --- ## Post #6 by @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\. --- ## Post #7 by @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 --- ## Post #8 by @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 --- ## Post #9 by @USM_Bish1 > > 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 --- ## Post #10 by @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 --- ## Post #11 by @system \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #12 by @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 --- ## Post #13 by @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" --- ## Post #14 by @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 --- ## Post #15 by @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 --- ## Post #16 by @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 --- ## Post #17 by @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 --- ## Post #18 by @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 --- ## Post #19 by @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 --- ## Post #20 by @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 --- ## Post #21 by @Karsten_Hilbert > > 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\. > 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 That then means you can do this: \- check if there are first names \- if yes   \- check if the initials match   \- if yes     \- forget the initials: you can recreate them   \- if no     \- store them but don't worry about what they mean       because you cannot know what they mean \(eg the source       system does not provide that information\) \*see below \- if no   \- assume the initials \*are\* the first name initials   \- store them in the firstnames field directly \*\) Now, of course, one doctor will come up and say "But I always used that field to store the stardate equivalent of that patient's grandmother's marriage \!" In that case \(if you want to keep that information for that doctor\) you should postprocess the data exported from his source system and store the data in a new field patient\_grandma\_marriage\_as\_stardate in your system\. Only half kidding\. Karsten --- ## Post #22 by @system Dear colleagues, The CEN standards as told before, are consensus products at an abstract level\. This implicates that they need an Implementation specification in order to be usable\. You and others must produce those\. OpenEHR is such a forum\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #23 by @system Extending qualifiers is allowed\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #24 by @system > Extending qualifiers is allowed\. See, see, the Convenor of CEN TC251 Wg 1, thanks, thank you very much Gerard, I really appreciate\!\!\!, this quick move\. It was within the three days I said I could affort to wait\. Next week I will try some more questions\. Have a nice weekend\. Kind regards Bert Verhees --- ## Post #25 by @USM_Bish1 > \[some snipped\] > > 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, you have driven home the point\. Look at the variances in what a simple thing like 'initials' may mean ;\-\) For OpenEHR to proceed as an international foundation, we need to talk a common language, understood by everybody, the same way\. There is a need for the following: o Demographic entities need to be defined by us, and archetyped\. o Since this links up with every subsequent entry, this section   has to be based on philosophies of the 'HCF' \(Highest Common   Factor\)\. o All nomenclatures used for such definitions should be culture   neutral, and as generic as possible\. o Once the 'definitions' are made and accepted, developing the   archetypes would become simpler\. Things would fall into place   one by one\. Demographic details are one of the toughest parts of any data base\. In a multicultural society like mine, I do know what it means, and realise its importance\. As regards 'initials' are concerned look for the word 'initial' on dict\.org \(the definition of about 5 dictionaries are given\)\. However, perhaps better understood, with the following example: What would you expect, if you ask me to 'initial' a document as having seen\. Do you expect 'USM' or 'USMB' ? If I ask you to do the same, I would expect you to place 'KH' and not just 'K'\.IOW 'initials' are the first letters of the whole name in order of usage\. Some societies use Family name in the beginning, so for them the order may differ in the initials from convention\. Just my 2p USM Bish Bangalore --- ## Post #26 by @thomas.beale Karsten Hilbert wrote: > I do not completely understand why you need to be able to > \*process\* initials ? > You definitely do\. If your name is "F\. Murray Abraham" \(to use the name of the actor who played Salieri in "Amadeus"\) and that's what you present yourself as, then the EHR system had better not mess it up\. It probably should record what the "F\." stands for, but still needs to remember that it is always used in the initial form with both the patient, the health service and payers\. \- thomas beale --- ## Post #27 by @Karsten_Hilbert I understand that\. Let me rephrase my question: I do not completely understand why you need to be able to \*process\* first name initials any different from fully spelt out first names ? Karsten --- ## Post #28 by @lakewood Hi Thomas and Karsten, Names are unusual\. We have 'official' names \(e\.g\., birth certificate\) and 'unofficial' names \(e\.g\., those we choose ourselves and others we are given\)\. A brother migrated to the Southern US states, married and had four children\. I remember 'Gator' and 'Armadillo'; I can't remember the official names and they probably do not like using them\. My wife's first and middle names at birth were 'Jacqueline' and 'Elizabeth'\. The British Nurse that registered them did not like the arrangement and she placed 'Elizabeth' first\. She is now 'Jacqueline' and the 'Elizabeth' has been dropped except for the INS\. My sad case is that I was labelled as 'TJ' the first and middle initials\. That was corrected after I gained adulthood and started signing up for various things\. If I happened to take either of my brother's children to a Healthcare Facility and I had to provide someone with relevant information, then it has to be 'Gator' and 'Armadillo'\. It is unrealistic to presume the Southern US states can sort this out and the rest of this country is similarly peculiar\. For example, some Native Americans prefer to use a single name\. Since we presume a minimum of three a problem arises and more information is needed\. Personally, names should be 'localized' with variable formats\. Some co\-workers have asserted their right to have multiple last names\. There was never enough room on the form\. Then there are the places where everyone has the same last name, no middle name, and little variety in the first name, e\.g\., you should know who you are talking to\. The INS attempted a solution some time ago by changing the names, which is why there is no 'e' on the end of mine\. Even though people ignore the name change, anyone caught herein without a proper INS name is in real trouble\. Flexibility is needed since there are many more variations yet to be encountered\. Regards\! \-Thomas Clark Karsten Hilbert wrote: --- ## Post #29 by @system What are names? What are names used for? Names are nothing but a set of strings consisting of characters\. What are names used for? Most often we need them to add new information to the correct file\. \(Correct meaning the file of the same person we saw the previous time\) Names are to add a new document to other documents\. And this collection of documents are about the same person\. Sometimes we need a name in order to be able to attach it to a person\. We need a name because we have to use the correct name to send the bill\. Sometimes we really need to know the real identity of a person\. In most cases the real identity is not important\. We only need an identifier to locate documents\. In other words what is the use case we are talking about? Once we know this, we know what we are talking about\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #30 by @USM_Bish1 Gerhard, this is based on my experience of having a very modest, plain vanilla XML based EHR operational for GP practice over a chain of clinics at Bangalore for over two years now\. It is gradually moulding with use, but enough to answer your question of 'What are names used for'\. Names are a set of strings, but they have definite purpose\. o In our database, the name string consists of 4 components as   follows:   Namestring = 'IndexName, OtherNames, \(AKA\), Initials'   e\.g\. 1\. 'Bond, James, \(Jim\), JB'              2\. 'Edison, Thomas Alva, \(Tom\), TAE' o We do NOT use this string as a document identifier\. Identity   is done by 'unique usernames', based on the above\. For James   Bond, the username would be 'bond\_jb0000'\.   \(IOW, we have catered for 10000 Bonds with same initials of   'JB'\. We now realise that this 10000 figure is perhaps a bit   too much, but it is safe, adequate for 100 years at least \!\)    o The AKA, bit is important because some out\-of\-clinic records   may have annotations like 'Jim Bond' and we know where to   fit such things\. o The initials are used for labelling bottles and slides where   there is not enough space to write a full name identifier\.   Keeping the Initials in the database ensures commonality and   precludes human error\. Somebody may notice 'Bond, James' and   and write the initials as 'BJ' \!      \(Though samples are also numbered, this is a crosscheck for   avoiding sample mix\-ups at the lab level\. Dual identifiers   for samples reduces the chances of mix\-ups significantly\. We   have had NONE at our centralised lab in last 2 years\)\. o The full name also helps in administrative processing of the   documents for financial and legal purposes, besides ofcourse   searches \(as you mention\)\.    We have found this system to be working quite smoothly, as of now\. It would be interesting to know what other prople use this name string for\. Or, what other components do they use \.\.\. Bish --- ## Post #31 by @lakewood Hi Gerard, Good response; see test\. Regards\! \-Thomas Clark Gerard Freriks wrote: > What are names? > What are names used for? > > Names are nothing but a set of strings consisting of characters\. > What are names used for? > The applications are many, local/global, known to the individual and unknown\. > Most often we need them to add new information to the correct file\. \(Correct meaning the file of the same person we saw the previous time\) > Names are to add a new document to other documents\. And this collection of documents are about the same person\. > Many databases \(include Healthcare\) utilize one or more numbers as indexes since a number is not sensitive to some of the problems of names, e\.g\., "\.\.\. Maria Theresa, archduchess of Austria, Holy Roman Empress, and queen of Hungary and Bohemia \.\.\." What is her PatientID ? Names are used to produce a minimum set of potentially correct PatientID numbers with the proviso that the correct PatientID many be missing, e\.g\., insufficient information, but the search algorithm is likely designed to output only previously verified information, not correct information\. Catch\-22\! The individual claims to be 'Maria Theresa' and upon further investigation reveals that she \(hopefully\) is none other than the 'archduchess of Austria, Holy Roman Empress, and queen of Hungary and Bohemia'\. Call the Special Branch and the fingerprinting and photo divisions\. Caveat: Relying on names to run a database might be risky\. Using them as 'tags' to retrieve or create a PatientID is better, with the second caveat that one individual might end up with multiple PatientIDs\. Aside: Happened to me at my HMO \(twice\)\. Was surprised to discover I had those problems\. Relieved to see that the Practitioner was able to 'Wing It\!"\. > Sometimes we need a name in order to be able to attach it to a person\. > We need a name because we have to use the correct name to send the bill\. > You have me here\. I am unable to think of a single case in this society where an individual does not have a name\. Maybe in other societies\. Here a corpse on the street even gets a 'Jane/John Doe' and a 'case number'\. > Sometimes we really need to know the real identity of a person\. > Actually, even beyond Healthcare issues, at all times we need to know the 'real identity of a person'\. Exception for Intelligence Services and others whose can function only with deceit\. > In most cases the real identity is not important\. > We only need an identifier to locate documents\. > In most cases 'the real identity' is important, at least in this society\. Medical errors alone kill anywhere from 100,000 to 300,000 people per year and a significant percentage of these cases result from improper drugs, e\.g\., Who was that Patient\. Lost a friend and a neighbor that way\. > In other words what is the use case we are talking about? > Once we know this, we know what we are talking about\. > What 'use case' in Healthcare does not require precise knowledge of the Patient's real identity? --- ## Post #32 by @system Hi, When I buy a loaf of bread nobody needs my name\. And this is true for many transactions in society\. When I need stitching up a wound, they don't need to know my rel identity\. And this is true for many situations in real life\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #33 by @Tim_Cook6 Research; among others\. --- ## Post #34 by @Sam Dear All I have been working with DV\_MULTIMEDIA and feel that the thumbnail feature should be a JPEG rather than a DV\_MULTIMEDIA\. I believe this is the way to go as although it restricts the thumbnail to an image \- it means that everyone can view the thumbnails\. It also means we do not have a cyclical definition\. The danger is fixing to a particular technology \- but I think in this case it is worth it\. Thoughts? Sam Heard --- ## Post #35 by @Kevin_Coonan_MD This is a routine occurrence in Emergency Medicine\. Often patients have multiple identities or are in a state where their identity can only be approximated \(e\.g\. middle aged male\) due to patient condition\. Also, if someone presents in acute distress/trauma many systems use a dummy ID, which is used for orders, labs, etc\. and when the patient is stabilized, family arrives, etc\. their dummy registration is linked to, and subsumed by, their real identity\. Finally, anonymous testing doesn't have knowledge of the patients identity, beyond that of system assigned code\. Kevin --- ## Post #36 by @lakewood Hi Gerard, The 'loaf of bread' is true here\. The 'stitching up a wound' for a Healthcare Practitioner is not for a variety of reasons that include issues from Homeland Security to potential future lawsuits\. The reporting requirements associated with 'rendering medical assistance' can change from Juridiction to Jurisdiction and from Insurance Company to Insurance Company, but on a global scale it is a good idea to 'widen' the EHR to sufficiently cover the maximum requirements\. Expect 'pushback' if the standard does not require the identity of the Patient be included in the report being filed, and expect to be required to file a report\. Additionally, when 'stitching up a wound' you are in many cases 'rendering assistance', e\.g\., 'post\-injury'\. A multitude of 'situations/cases' spring to mind that can/have involved other organizations with a potential interest in the 'injury' and the 'post\-injury assistance'\. Should check further\. Regards\! \-Thomas Clark Gerard Freriks wrote: --- ## Post #37 by @Karsten_Hilbert For $DEITY sake, come on \! After all, people with bad intentions feed on bread, too, so why not require the bakery shop to report on any of them byuing foodstuffs, too ?? Keep it real\. There is a life\. Karsten, A Euro Whimp --- ## Post #38 by @lakewood Hi Kevin, Agree\! The 'precise knowledge of the Patient's identity' is limited by the circumstances and the Healthcare Provider is protected where efforts have been made to completely identify the Patient in the presence of uncertainty\. For the duration of treatment 'identity' can be a 'dummy ID' or a 'case number', both of which can be expanded and linked to newly acquired 'identities'\. 'anonymous testing' is rooted in Patient Privacy and 'identity' is established as above, e\.g\., 'dummy ID'\. A Lab number can be assigned or another mechanism used to protect privacy\. Historical Anonymous Research: The 'anonymous' protected the research but there were still records of the research and the participating Patients\. These practices have been addressed in many Jurisdictions and Patient protections are considerably 'wider' today\. Someone then knew the Patient's identity; today the reporting/verification requirements are more stringent\. 'Anonymous research' is showing up in many areas where the effectives of certain drugs have been shown to be close to if not ZERO and the drugs have been recalled\. With time, money, credibility and reputation wasted, along with the fatal and potentially fatal impacts of side effects on Patients, whatever it was that was used to justify this mess should in no way be referred to as 'research'\. Full disclosure is necessary prior to certification\. Effectiveness is a key component of any such certification\. Proof is required\. Future: Presuming that Genetics\-based medicine has a future it seems that a position that the 'real identity' of the Patient need not be known is untenable\. Gene scans are available commercially now and the prospectus of many drug companies include plans for gene\-based drugs\. It appears that the trend is moving in the direction of knowing the 'real identity' of the Patient\. Situations where the Patient's 'identity' is limited to 'current knowledge' will be restricted dependent upon the extent of that knowledge\. Emergency Medicine will always be a special case and will require in some cases a 'chain\-of\-identity' for particular Patients\. The chain may takes considerable time to complete and it may never be completed\. For an EHR system the capability of handing every EM Patient is a requirement\. Regards\! \-Thomas Clark Kevin Coonan, MD wrote: --- ## Post #39 by @system Hi, Instead of a lot of attention to arcane things like name, identity, etc we need to know whether the patient belongs to a stored document, and vice versa\. So a jpeg is an excellent way to do just that\. A jpeg is infinitly better than a strange number\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #40 by @Tim_Cook6 I believe that fixing 'thumbnail' to a specific technology makes sense\. I haven't been able to come up with another function that could be equated with thumbnail other than 'viewing a reduced size image'\. Certainly you could have portions/compressions of other multimedia content but they would be called summaries, extracts, abstracts, etc\. of the content\. I do think if we are going to specify a technology it should be as open as possible\. Portable Network Graphics\(\.PNG\) works everywhere and works equally well with either line or continuous tone image data\. If anyone wants to review the various options here is a quick overview: http://www.devx.com/projectcool/Article/19997/0/page/3 Cheers, --- ## Post #41 by @lakewood Reference on Universal Patient ID: http://www.fortherecordmag.com/archives/ftr_011705p34.shtml Medical errors are important\! Regards\! \-Thomas Clark Karsten Hilbert wrote: --- ## Post #42 by @grahamegrieve I've just tried to catch up on this thread\. Other than the perennial issue of datatype vs\. archetype, I didn't catch anything in the content that pointed a problem with the specifics of the HL7 V3 model for Entity Name\. Why is CEN partially different from HL7 \(i\.e\. not qualifier for initials?\) I think that the qualifier for initials is quite troublesome \- If I know that the person has an initial D and a first name Richard, is D the initial for Richard? This kind of question only comes up on demographics servers, but I don't see any of the forms of representation mentioned in this list helping me with this\. \(Though I read it real quick\) Grahame --- ## Post #43 by @grahamegrieve Regarding OIDs and II, I think there's a misunderstanding about the point of the OID part of the II The OID is computationally opaque \- it's not intended to tell you anything about the identifier, only to make it unique\. Any scheme based on reverse engineering the OID into some form of information about the II that contains it will founder\. Even if we turned around and based it on DNS, it still founders\. The point is that the context of the II tells you what kind of identifier it is\. OK, I lie\. I see that in it's common usage, certainly in HL7 and apparently in CEN and openEHR \- though I haven't checked \- things have a SET<II> or equivalent, which requires that the II semantics themselves tell you more than simply the value of the identifier\. So I see a mismatch between the intention of II and it's use\. The problem with information about the identifier is that it's rather hard to come up with a formal strategy for providing metainformation about the II\. Take for instance, the HL7 V2 mess of codesets for describing the source identifier type\. As a HL7 V2 implementor, I know that it's done by site specific decisions, since the mess is too far out of control\. And V2\.6 will only make this worse\. Rather like doing it by OID, and configuring it by hand\. I wouldn't want to be writing a general nation\-wide HL7 receiver that had to sort out identifiers\. No wait, I did write such a spec for Australian usage\. And we took considerable care to nail down the Identifier usage so that this situation didn't arise\. only possible solution \- though I very much doubt it's feasible \- is for there to be an LDAP based health OID repository to allow dynamic querying of the OID metadata\. Sure, this would mean that you'd need a live internet connection to do the query, but if you really are writing a general case data mining tool with no ability to nail the identifiers down in your incoming data, then this is the least of your worries\. Grahame --- ## Post #44 by @system > I've just tried to catch up on this thread\. > Other than the perennial issue of datatype > vs\. archetype, I didn't catch anything in > the content that pointed a problem with the > specifics of the HL7 V3 model for Entity Name\. > Why is CEN partially different from HL7 \(i\.e\. > not qualifier for initials?\) > > I think that the qualifier for initials is > quite troublesome \- If I know that the person > has an initial D and a first name Richard, is > D the initial for Richard? This kind of question Did you mean D\. Richard Hipp? Often called Dr\. Hipp, but he never pretended to be a Dr\. --- ## Post #45 by @grahamegrieve > > > I think that the qualifier for initials is > > quite troublesome \- If I know that the person > > has an initial D and a first name Richard, is > > D the initial for Richard? This kind of question > > Did you mean D\. Richard Hipp? > Often called Dr\. Hipp, but he never pretended to be a Dr\. Richard is often abbreviated to Dick in English usage\. No idea what the origin is \- lost in the mists of time\. So, if you get    initial = D    given = Richard you don't know that the D is an abbreviation for Richard\. And if you do know that it is, there's no way to say so Grahame --- ## Post #46 by @system > Regarding OIDs and II, I think there's a misunderstanding > about the point of the OID part of the II > > The OID is computationally opaque \- it's not intended to > tell you anything about the identifier, only to make it > unique\. Any scheme based on reverse engineering the OID > into some form of information about the II that contains > it will founder\. Even if we turned around and based it on > DNS, it still founders\. > > The point is that the context of the II tells you what > kind of identifier it is\. What if the context is patientExtendedInformation? A patient can carry many identifiers\. > OK, I lie\. I see that in it's common usage, certainly in > HL7 and apparently in CEN and openEHR \- though I haven't > checked \- things have a SET<II> or equivalent, which requires > that the II semantics themselves tell you more than simply > the value of the identifier\. > > So I see a mismatch between the intention of II and it's use\. I don't know what the intention was, but the use, is to present one or more identifiers, connected to an entity\. It seems to me a good use\. > The problem with information about the identifier is that it's > rather hard to come up with a formal strategy for providing > metainformation about the II\. Take for instance, the HL7 V2 mess > of codesets for describing the source identifier type\. As a HL7 V2 > implementor, I know that it's done by site specific decisions, since > the mess is too far out of control\. And V2\.6 will only make this > worse\. Rather like doing it by OID, and configuring it by hand\. I > wouldn't want to be writing a general nation\-wide HL7 receiver that > had to sort out identifiers\. I do not want to substitute OID by metainformation, but add metainformation to II, as an extra property\. A qualifier, like "insurance\_number", "social\_security\_number", "local\_system\_id", etc > No wait, I did write such a spec for Australian usage\. And we took > considerable care to nail down the Identifier usage so that this > situation didn't arise\. > > From my perspective \(V2 implementor and V3 data types editor\), the > only possible solution \- though I very much doubt it's feasible \- is > for there to be an LDAP based health OID repository to allow dynamic > querying of the OID metadata\. Sure, this would mean that you'd need > a live internet connection to do the query, but if you really are > writing a general case data mining tool with no ability to nail > the identifiers down in your incoming data, then this is the least > of your worries\. Even the least of all worries still is a worry, and it depends\. I am not writing a general datamining tool, but I am writing a CEN layer to present data from local GP\-systems in a standarized form\. This works fine, and third parties know where they can find their data, independent of the underlying GP\-system\. And the patient carries a few identifiers, in a Set, and I want to mark one of the identifiers as an insurance\-number\. That is all\. Though, the layer I am writing can be used for datamining, and will be used as such, but there are many more uses\. I have no complaint about market\-interests\. --- ## Post #47 by @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 --- ## Post #48 by @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 --- ## Post #49 by @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 --- ## Post #50 by @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 --- ## Post #51 by @Karsten_Hilbert > > 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\. > 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 That then means you can do this: \- check if there are first names \- if yes   \- check if the initials match   \- if yes     \- forget the initials: you can recreate them   \- if no     \- store them but don't worry about what they mean       because you cannot know what they mean \(eg the source       system does not provide that information\) \*see below \- if no   \- assume the initials \*are\* the first name initials   \- store them in the firstnames field directly \*\) Now, of course, one doctor will come up and say "But I always used that field to store the stardate equivalent of that patient's grandmother's marriage \!" In that case \(if you want to keep that information for that doctor\) you should postprocess the data exported from his source system and store the data in a new field patient\_grandma\_marriage\_as\_stardate in your system\. Only half kidding\. Karsten --- ## Post #52 by @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 --- ## Post #53 by @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 --- ## Post #54 by @system Bert, In what way do you suggest should CEN change the standard\. Now is the time to make a proposal\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #55 by @system > Bert, > > In what way do you suggest should CEN change the standard\. > > Now is the time to make a proposal\. I can only talk about the things I have encountered, and my general impression for that small part I have seen, is that it has been well thinking, that has been done\. As far as I can judge, which is not far, I am not a specialist for medical informatics\. I am a programmer\. And that is another point of view\. I have some suggestions, I will come back to them later\. But in two months or so, I will have some more suggestions\. It is late, and tomorrow will be a long day\. I come back to this question at the end of the week Thanks for asking Bert --- ## Post #56 by @Karsten_Hilbert > Richard is often abbreviated to Dick in English usage\. > No idea what the origin is \- lost in the mists of time\. > > So, if you get >   initial = D >   given = Richard > > you don't know that the D is an abbreviation for Richard\. > And if you do know that it is, there's no way to say so Well, is there a \*need\* to say so ? What's fundamentally wrong with just storing the D as a second first name along with Richard ? I probably am too much of a pragmatist\. Karsten --- ## Post #57 by @grahamegrieve hi Karsten depends which hat I'm wearing\. If I'm programming, then I probably won't care \- delegate the problem to the user\. If I'm wearing my standards hat, or writing a reference demographics server, then I would care Grahame --- ## Post #58 by @system Karsten Hilbert wrote: >> Richard is often abbreviated to Dick in English usage\. >> No idea what the origin is \- lost in the mists of time\. >> >> So, if you get >> initial = D >> given = Richard >> >> you don't know that the D is an abbreviation for Richard\. >> And if you do know that it is, there's no way to say so >>    > Well, is there a \*need\* to say so ? What's fundamentally > wrong with just storing the D as a second first name along > with Richard ? I probably am too much of a pragmatist\. > > Karsten > The discussion about how people should call themselves is in my opinion not a good discussion\. You have to deal with a person, and the name he gives to you\. There are no rules\. F\.e\. there are refugees who do not want to tell their real name\. Do they have a right for medical care? If yes, you have to deal with the name you get from them\. That is all you will get\. And if someone calls himself: D\. Richard Whatever, you can store untill further notice: Given Names: D\. and Richard Initials: D\. R\. Lastname: Whatever The only thing you can do is to cover as much as possible the normal situations, and a qualifier for "initials" can help me in a special situation I am working for\. I really do not see the problem with this\. It depends, as Grahame says, which hat one is wearing\. A Information System Standard which will be suitable for many applications, should give support the purpose of those applications\. If it does not, it is not useable for those applications, than that will be bad news\. Which hat is the Standard wearing? Regards Bert Verhees --- ## Post #59 by @Karsten_Hilbert > The only thing you can do is to cover as much as possible the normal > situations, and a qualifier for "initials" can help me in a special > situation I am working for\. Ah, that answers my question \! The reason you feel a need to process initials is that you \*want\* to be able to process them\. And now you are looking for a way to process them according to a standard\. You are \*not\* looking for "just a way to deal with them" which is what I was trying to suggest\. Understood\. Karsten --- ## Post #60 by @Karsten_Hilbert I was commenting on the mention of Homeland Security as a reason for requiring identification when stitching up a wound\. Karsten --- ## Post #61 by @system \-\-\-\-\-\-\-\-\-\- Doorgestuurd bericht \-\-\-\-\-\-\-\-\-\- --- ## Post #62 by @system We must get used to the notion that patients not always have to provide their real names\. And that in order to provide healthcare we need to know the real \(administrative\) identity\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #63 by @system Dear all, My ideas: \- unique identifiers are numbers that are unique\. \- each collection of information that has an attribute with this unique number can be collected and presented as belonging together, \- with one unique identifier per \(pseudo\)identity all information belonging to this unique identifier can be collected and presented as belonging together \- this type of use is identifying documents \(or parts of it\) as containing information about the same person with a specific identity\. \- it is NO PROOF of the real identity of the person\. That is a different matter\. \- When we have to uniquely identify persons we need other things than numbers\. \- Unique numbers must not be trusted\. \- Unique numbers that identify persons generate problems: identity theft\. \- Only knowledge that is known by the person, or features his body posesses, will help to identify persons\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #64 by @system > Dear all, > > My ideas: > \- unique identifiers are numbers that are unique\. this is not true, not the numbers are unique, the number in context of something \(social security, insurancenumber, etc\) is or should be unique\. > \- each collection of information that has an attribute with this unique > number can be collected and presented as belonging together, it is not that simple, a collection of information can have more then one number, and the CEN\-standard does not provide meta\-information in some cases, f\.e\. PatientExtendedInformation carries a Set<II>, which is a set of numbers \(identifiers\), those numbers in a list do not have meta\-information, except for the OID, but that meta\-information can only be resolved over a network\-service \(which does not yet exist\)\. f\.e\. You retrieve a PatientExtendInformation\-object from a information\-system\. And it carries a few numbers\. You have to know which one is the socialsecurity number, you have to resolve the OID\. That is possible, when you have an Internet connection and the resolving OID\-service is up and running, which not always may be the case\. We are talking about a standard CEN, which has the intention to solve all information problems world\-wide Sometimes you don't have an Internet\-connection \(f\.e\. firewall restrictions\) Sometimes the OID is not know at the resolving service \(OID from an other country, which has no resolving OID exchange with our country\) Sometimes there is no OID \(a less developed country\) Sometimes the resolving service is unreachable \(down, hacked, whatever\) But, even when this is all working well, the following situation You are online datamining, and you do not retrieve one PatientExtendedInformation, but 1\.000\.000\. The fact that you have to resolve all OID's will slow your datamining down very much, and unnecessary\. It could slow down that much that it is unacceptabel for a customer, and the world has to live without that datamining application, or the customer will want to look for another standard to work with\. I once wrote an application which did analyse firewall\-logging, the analysing was a matter of seconds, some nifty mathematical algorithms over the logging database\. But then the customer also wanted to know from which companies the IP\-addresses where coming from, so the analysing application had to resolve the IP\-addresses\. Happily, DNS is a very good system, worldwide implemented \(although there are problems with NAT, which is sometimes region wide \-implemented \(China\) because of lack of unfair sharing of availble IP\-addresses\) The customer was not happy, first the application slowed down, what was first done in a few seconds, took an hour ore more \(factor 1000 or more\), second, the result was not satisfactory because of NAT and other resolving issues\. This problem can easily be solved when the II\-object is extended with a qualifier which tells us what kind of an II you are looking at\. f\.e\. You want to know at which insurance company a million of patients are insured, and every patient carries 10 numbers, without this qualifier you have to resolve 10 numbers from each patient to find that one which is of interest, that means 10\.000\.000 resolving actions, where 1\.000\.000 would do if there was a qualifier, it means 9\.000\.000 resolving actions too many > \- with one unique identifier per \(pseudo\)identity all information > belonging to this unique identifier can be collected and presented as > belonging together > \- this type of use is identifying documents \(or parts of it\) as > containing information about the same person with a specific identity\. > > \- it is NO PROOF of the real identity of the person\. That is a > different matter\. > > \- When we have to uniquely identify persons we need other things than > numbers\. > \- Unique numbers must not be trusted\. > \- Unique numbers that identify persons generate problems: identity > theft\. > \- Only knowledge that is known by the person, or features his body > posesses, will help to identify persons\. It, thus, its only use is not to identify a person, that is only one purpose of an information system\. Also there is an other problem with OID's, a identity may not have an OID, I guess this will happen a lot, certainly in the coming few years\. In that case, there has to be an OID which indicates that there is no\-one\. This is necessary because OID is a mandatory property in the II\-type\. In that case, your need for a qualifier is even more urgent\. There may be other solutions then a qualifier to this problem, but the current situation in the standard is in my opinion not sufficient regards Bert Verhees --- ## Post #65 by @system > We must get used to the notion that patients not always have to provide > their real names\. > And that in order to provide healthcare we need to know the real > \(administrative\) identity\. When you build a system that is only usable when you have a working Internet\-connection, in my humble opinion, this is a bad system\. There are many situations where you don't have good networks, think of war, tsunamies, big disasters, maybe you want to register people for the healthcare they get, but if a stupid application refuses to accept a patient, because the OID cannot be resolved \(when you say mandatory to a programmer, he will make it mandatory\), tha application will be useless\. But this example is beyond the scope of my problems \(for now\)\. Bert --- ## Post #66 by @system Disasters or not\. This is not what I ment\. In real life we buy a loaf of bread without a full identication\. In real life I get healthcare without the need for the care providers to know my name\. And when I pay in cash they don't need my bank account number\. The only need a unique identifier \(set of\) to find records filed previously\. Any unique thing will work as well\. A real name, address, data of birth, or my bankaccount, the date of my mothers birthday, a token, a phoney name, or an other unique thing like a series of scars on my skin, a photograph, my fingerprint, etc, etc Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #67 by @system Thomas, Will you bring this topic up in Berlin? Gerard --- **Canonical:** https://discourse.openehr.org/t/entitynameparts/14480 **Original content:** https://discourse.openehr.org/t/entitynameparts/14480