EntityNameParts

2005-04-26 Thread 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.

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


OIDs / II

2005-04-26 Thread Gerard Freriks
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
On 20 Apr 2005, at 12:43, Bert Verhees wrote:

 Dear Grahame,

 For example the CEN GPIC subjectofcare which has a property id
 The type is a Set of II
 The use is excplained as:
 An identifier or identifiers that may be used to uniquely identify the
 subject of care.
 Examples: social security number, health service number, hospital
 number, case notes number

 Please indicate where there is a mismatch between the intention and the
 use of II.

 CENTC251 could learn from that. It would be a great benefit to the
 standard if this would be sorted out.
 And if it will, then the need for an extra qualifier to tell which the
 type of identifier is presented, may disappear, depending on your 
 solution

 Kind regards
 Bert Verhees
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1829 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050426/14704952/attachment.bin


OIDs / II

2005-04-26 Thread Bert Verhees
Op dinsdag 26 april 2005 07:52, schreef Gerard Freriks:
 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 SetII, 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


 Gerard


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

 +31 252 544896
 +31 654 792800

 On 20 Apr 2005, at 12:43, Bert Verhees wrote:
  Dear Grahame,
 
  For example the CEN GPIC subjectofcare which has a property id
  The type is a Set of II
  The use is 

EntityNameParts

2005-04-26 Thread Bert Verhees
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



Specification Humor

2005-04-26 Thread Tim Cook
..and on the lighter side:

http://lists.xml.org/archives/xml-dev/200504/msg00260.html

http://lists.xml.org/archives/xml-dev/200504/msg00245.html

Have a great day!

-- 
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/20050426/ae6b84eb/attachment.asc


uncertainty in medical problem solving and decision making (Was: Dr R LONJON Confidence indicator !

2005-04-26 Thread lakew...@copper.net
Hi Arild,

Another site is the MIT Group on Clinical Decision Making: [ 
http://medg.lcs.mit.edu/ ].
... a research group dedicated to exploring and furthering the 
application of technology and artificial intelligence to clinical 
situations. Because of the vital and crucial nature of medical practice, 
and the need for accurate and timely information to support clinical 
decisions, the group is also focused on the gathering, availability, 
security and use of medical information throughout the human life 
cycle and beyond ...

Unfortunately Patient decision-making receives less emphasis and studies 
seem to miss some
fundamental factors (e.g., it is private)
[ http://www.ahrq.gov/research/rtisumm.htm ]

Regards!

-Thomas Clark

Arild Faxvaag wrote:

 Hi all.
 This is an important topic. Here are some references / pointers for 
 those who wish to read more:

 Decision making in health and medicine. Integrating evidence and 
 values Myriam Hunink and Paul Glasziou Cambridge university press 
 (ISBN 0 521 77029 7)

 Society for Medical Decision Making: http://www.smdm.org/

 I also recommend journal articles written by Wimla L Patel (Colombia 
 university, New York), for instance:
 http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrievedb=pubmeddopt=Abstractlist_uids=11418539
  

 (A primer on aspects of cognition for medical informatics)

 regards
 arild Faxvaag

 P
 22. apr. 2005 kl. 07.42 skrev Gerard Freriks:

 -1- Almost never a diagnosis is 100% certain.
 -2- Almost always a test result has uncertainty attached to it
 -3- Many times a conclusion is reached based on many uncertain and
 conflicting facts
 -4- Quite often a condition, a diagnosis, is assumed that gives
 rise to a treatment. Not indicating that the patient is suffering
 from this condition but using treatment as a test procedure. Doing
 nothing is such a test procedure.

 Eric Wulff (from Danmark) published philisophical texts about
 health care and these topics.

 gerard

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

 +31 252 544896
 +31 654 792800
 On 20 Apr 2005, at 13:58, Thomas Beale wrote:

 I'm wondering if there is a meta-algorithm of some sort
 lurking behind the scenes, which takes account of uncertainty
 in a note, and also severity of non-discounted possibilities,
 as a way of deciding what to do next. There is undoubtedly
 published work on this...

 thoughts?

 - thomas beale

 -- 
 Arild Faxvaag
 associate professor / rheumatologist
 Adress / Office St.Olavs hospital:
 Department of Rheumatology, St.Olavs hospital N-7006 Trondheim, Norway
 Phone Dept of Rheumatology 47 7386 7263

 Adress / Office NTNU
 Norwegian center for electronic patient records research (NSEP)
 Medisinsk teknisk forskningssenter
 N-7489 Trondheim

 Cellphone: 47 9821 6825
 http://www.ntnu.no/~arildfa/ (home page NTNU)
 http://www.usemed.com (weblog on e-medicine)
 http://www.ehr.ntnu.no/e (Norwegian Centre for Electronic Health 
 Records Research)

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org