EntityNameParts
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 On 26 Apr 2005, at 09:56, Bert Verhees wrote: Op dinsdag 26 april 2005 07:37, schreef Gerard Freriks: 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 Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 17 Mar 2005, at 13:50, Grahame Grieve wrote: At 11:29 PM 17/03/2005, you 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. 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 -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2855 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050427/e904c0ac/attachment.bin
EntityNameParts
In order to get proper treatment the identity can stay obscure. Identification is not a necessary condition for any treatment. Information is sometimes. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 27 Apr 2005, at 06:19, Grahame Grieve wrote: It's not the same. For various reasons care providers (may) need to properly identify their patients/customers. Healthcare may be provided on an anonymous basis under some circumstances, but the nature of these circumstances and the care provided will depend on jurisdiction -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 692 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050427/8f48b6a2/attachment.bin
EntityNameParts
Op woensdag 27 april 2005 00:31, schreef Gerard Freriks: 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. I agree, it is not the function of an information system to make a true identity mandatory, it should give other means to identify people unique. It must also give the opportunity for people to identify themselve always as unique, so there can not be a link between caretakings, if people do not want that in an special situation. It is the law which must decide in howfar an identity should be true, not the information system. We are talking about an information system/standard which has the intention of being worldwide useable, so it must be prepared for all kind of situations. When you say that an information system must follow a local law, you cannot use it worldwide, and you can get in trouble when the law changes. So you have to be very careful with the word mandatory in class-properties of Identity-related classes, before you know you are writing/implementing localised law/culture, instead of an information system with worldwide pretentions. Bert 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 On 26 Apr 2005, at 09:56, Bert Verhees wrote: Op dinsdag 26 april 2005 07:37, schreef Gerard Freriks: 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 Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 17 Mar 2005, at 13:50, Grahame Grieve wrote: At 11:29 PM 17/03/2005, you 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. 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 -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 On 17 Mar 2005, at 13:50, Grahame Grieve wrote: At 11:29 PM 17/03/2005, you 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. 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 -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1211 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050426/b5c55b72/attachment.bin
EntityNameParts
Op dinsdag 26 april 2005 07:37, schreef Gerard Freriks: 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 Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 17 Mar 2005, at 13:50, Grahame Grieve wrote: At 11:29 PM 17/03/2005, you 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. 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 -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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
EntityNameParts
Op dinsdag 15 maart 2005 11:34, schreef Grahame Grieve: 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. 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 -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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
EntityNameParts
Op vrijdag 11 maart 2005 11:42, schreef Karsten Hilbert: On Fri, Mar 11, 2005 at 10:31:09AM +0100, Bert Verhees wrote: Op donderdag 10 maart 2005 13:48, schreef 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: Where do you put initials and how do you qualify them as such so they can be recognized in an automated process. We don't have dedicated initials support. Most of the time (I know no other use) initials are the first character of the first name(s). So we either store them as first names (if we don't know the first name but know the initial) or we do not store them. I do not completely understand why you need to be able to *process* initials ? I am extracting data from existing systems, and put them in a CEN-structure (this is simplified saying of what I am really doing). I do not want to loose vital information in this process There is one system that stores person-data as - Roepnaam (dutch for call name) - Initials It is necessary that to distinguish as much as possible one person from another, both are known in the extracted data. The extracted data can be used for automated processing, so an automated process needs a qualifier to distinguish as callname from initials. That's why Karsten -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Fri, Mar 11, 2005 at 10:31:09AM +0100, Bert Verhees wrote: Op donderdag 10 maart 2005 13:48, schreef 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: 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 ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
Op vrijdag 11 maart 2005 12:34, schreef Karsten Hilbert: On Fri, Mar 11, 2005 at 12:12:03PM +0100, Bert Verhees wrote: 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 -- regards Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Sun, 2005-03-13 at 07:57, lakewood at copper.net wrote: What 'use case' in Healthcare does not require precise knowledge of the Patient's real identity? Research; among others. -- Tim Cook Key ID 9ACDB673 @ http://www.keyserver.net/en/ -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050313/42e5559d/attachment.asc
EntityNameParts
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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Sat, Mar 12, 2005 at 09:28:37AM +, Thomas Beale 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. 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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 On 11 Mar 2005, at 01:26, Thomas Beale wrote: 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1385 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/f3b8d219/attachment.bin
EntityNameParts
Op vrijdag 11 maart 2005 08:37, schreef Gerard Freriks: 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 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Fri, Mar 11, 2005 at 10:31:09AM +0100, Bert Verhees wrote: Op donderdag 10 maart 2005 13:48, schreef 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: 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 ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
Op vrijdag 11 maart 2005 12:34, schreef Karsten Hilbert: On Fri, Mar 11, 2005 at 12:12:03PM +0100, Bert Verhees wrote: 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 -- regards Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
Op vrijdag 11 maart 2005 12:36, schreef 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. 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 Not clean but doable. Karsten -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 On 11 Mar 2005, at 09:09, Bert Verhees wrote: 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 -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1662 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/f963a139/attachment.bin
EntityNameParts
Extending qualifiers is allowed. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 11 Mar 2005, at 13:42, Bert Verhees wrote: Op vrijdag 11 maart 2005 12:36, schreef 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. 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 Not clean but doable. Karsten -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1057 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/8f12cede/attachment.bin
EntityNameParts
Op vrijdag 11 maart 2005 15:53, schreef Gerard Freriks: 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 Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 11 Mar 2005, at 13:42, Bert Verhees wrote: Op vrijdag 11 maart 2005 12:36, schreef 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. 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 Not clean but doable. Karsten -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Fri, Mar 11, 2005 at 12:34:39PM +0100, Karsten Hilbert wrote: [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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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 -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Wed, Mar 09, 2005 at 10:29:45AM +0100, Bert Verhees 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. 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
