The Uncertainty Decision was: Dr R LONJON Confidence indicator !
Hello, I read opinions expressed on the topic. This question is important in France. The government took the decision that all citizen is going to have an electronic medical file.personal (DMP acronym) In principle all physicians with the authorization of the patient will have an access to this medical file for me it is about a medical file published a little like a weblog (to private and controlled acc?s) It is completely different of the electronic medical file that every physician must create and hold up to date for his/her/its patient in his/her/its cabinet. we call it the software profession.( logiciel m?tier in french ) This DMP should receive information exported from the software profession of the physician. The difficulty is to decide: 1 - what information must be published, 2 - this information is it reliable, so that another physician can use him and not to ask for a new exam 3 - if the physician producer of information, has a space of liberty, so that his/her/its responsibility implication is not systematically.? The solution would be can be to differentiate well: 1 - an information validated by the physician and that gives him the opposable information statute. He/it accepts to hire his/her/its responsibility. It is an information that is certified by documents as the imagery, the biopsy, the biologic analyses. 2 - an information proposed by the physician and that gives him the likely, possible information statute, but of which the level of certainty is not sufficient to have the opposable information statute. In this case the responsibility of the physician, be able to not be put in reason, while using this information no validated like proof. It is a legislative and legal probl?me, that is different of a computer analysis, but that is real. Indulgence for my English and thank you. Dr R LONJON France Selon Gerard Freriks : > Sam, > > I agree. > > Suggestion > In otherwords any clinical (or non-clinical) concept model must be > able to express the view of the author about certainty. > 3 states are sufficient for starters: > likely (as default) > not-likely > certain > > When a person attaches new information to the EHR and is of the opinion > that whole or parts of a received extract (or EHR) need an other > qualifyer then via versioning he must be able to annotate this by > adding his beliefs about certainty. > > > Gerard > > -- -- > Gerard Freriks, arts > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > +31 252 544896 > +31 654 792800 > On 27 Apr 2005, at 23:25, Sam Heard wrote: > > > Arild and Tim > > > > This is clearly an issue. In the CIP project the group wanted to be > > able to say that a diagnosis was a working diagnosis. > > > > We have archetyped a number of concepts that I think will enable the > > clinician to express these levels of uncertainty without resorting to > > confidence ratings on all entries in the record. Arild has shown that > > you could not possibly do a mastectomy without rating your certainty > > at 100% - or you will be sued. And not treating a pneumonia in a > > newborn with a certainty of only 20% will probably get you in trouble. > > These sort of explicit ratings are - in my opinion - very problematic. > > > > The solution lies in the recording constructs used for many years: > > > > 1. To express differential diagnoses (with or without probabilities) > > and to note key excluded diagnoses as well. > > > > 2. To express a diagnosis as a problem (such as lump in left breast) > > even if the likelihood of cancer is 100% clinically until the > > histology is returned. > > > > 3. To be able to label a diagnosis as a working diagnosis - ie it is > > likely enough to warrant the current management - but not certain. > > Appendicitis is a good example. > > > > So the archetypes for problem, problem-diagnosis (specialised) and > > differential diagnosis should meet these needs. > > > > Comments? > > > > Sam -- - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Issue 1
Bert Verhees wrote: >Interesting subject in this email. But it came through > >Issue 1: > >--- >The use of in many programming languages reserved words in the HL7 datatypes. >I am talking about the datatypes: Set, Array. >--- > > Hi Bert, almost all the issues you mention in this thread are actually due to the HL7 data types, which CEN unfortunately decided to adopt/adapt a long time ago. Tom Marley and others have struggled to find an version of them which a) remains faithful to the idea of HL7 bu b) fixes some problems, like strange inheritance. Personally, I am much more straighforward;-) I don't find the HL7 data types a good design at all, generally, and have made available the reasons in various standards discussions, along with many others who have pointed out the same problems (such as you are now doing). The result of this recently has been: - an new ISO work item called "data types for clinical informatics" (or something very close to that), whcih will recognise 3 layers: inbuilt types (like in ISO 11404), general purpose clinical types (specified from requirements), and a 3rd layer for bindings to particular model systems, such as HL7. THis work would avoid name clashes and other problems prevalent in the HL7 data types. The part 3 should be part of the HL7 ISO standard, not the ISO data types standard (for reasons of sensible managing dependency, and just out of relevance), but HL7 of course wanted to put its specifications in the main new standard. - CEN is now in a position of having to determine what the data types should look like for EN13606. In theory, they should be part 2 of the standard-to-be I mention above. In practice, the data types required for EN13606 is not a hard problem. The total list for all structural attributes is as follows: - string (= ISO11404 CharacterString) - date_time (in ISO11404) - object_identifier (in ISO11404) - boolean (in ISO11404) - a multimedia type (probably = an Array in 11404) - coded_text (not in 11404) No substitutability is needed as far as I remember. So this list is very short, simple, and available in any object-oriented language. (Personally my recommendation to CEN is to define a set like this as the structural datatypes right now, taking them from layer 1 of the new ISO standard, which is more or less ISO11404. only the CodedText type needs to be added. This could be done easily, and while avoiding the problems of the HL7 CD etc types, such as qualifiers.) The next set of data types that is required is those which inherit from DATA_VALUE, which is the type of ELEMENT.value. This list is a lot longer, and has substitutability rules: - Date, Time, Duration, Date_time - Partial dates and times - Text (with language) - Coded Text - Quantity, Quantity Ratio, Quantity Range, Count - Identifiers of real world entities - Boolean/Bistate - State - Ordinal - Time specification - Uri - Encapsulated Multimedia - Parsable This is the list of types I would see being developed as part 2 of the new work item in ISO. For the moment, openEHR has a pretty reasonable list of types which correspond to these, which could be used, although that would be up to CEN to decide. >It is in some popular languages not possible to use some words to define your >own datatypes, or parts of the datatypes. >This makes it impossible to use the standard in that language as it is. > >A standard should be platform-independent (OS, programming-language), that is >why I think it is an important issue > >I worked around the issue by naming those types: HL7Set, HL7Array, and for >consistency, I named the other Collection-types also HL7... (HL7Bag and >HL7List). > > That is about what you have to do for the moment, in in fact, in part 3 of the new ISO standard, where there will be an HL7 binding, such names will have to be used. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The Uncertainty Decision was: Dr R LONJON Confidence indicator !
Sam, I agree. Suggestion In otherwords any clinical (or non-clinical) concept model must be able to express the view of the author about certainty. 3 states are sufficient for starters: likely (as default) not-likely certain When a person attaches new information to the EHR and is of the opinion that whole or parts of a received extract (or EHR) need an other qualifyer then via versioning he must be able to annotate this by adding his beliefs about certainty. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 27 Apr 2005, at 23:25, Sam Heard wrote: > Arild and Tim > > This is clearly an issue. In the CIP project the group wanted to be > able to say that a diagnosis was a working diagnosis. > > We have archetyped a number of concepts that I think will enable the > clinician to express these levels of uncertainty without resorting to > confidence ratings on all entries in the record. Arild has shown that > you could not possibly do a mastectomy without rating your certainty > at 100% - or you will be sued. And not treating a pneumonia in a > newborn with a certainty of only 20% will probably get you in trouble. > These sort of explicit ratings are - in my opinion - very problematic. > > The solution lies in the recording constructs used for many years: > > 1. To express differential diagnoses (with or without probabilities) > and to note key excluded diagnoses as well. > > 2. To express a diagnosis as a problem (such as lump in left breast) > even if the likelihood of cancer is 100% clinically until the > histology is returned. > > 3. To be able to label a diagnosis as a working diagnosis - ie it is > likely enough to warrant the current management - but not certain. > Appendicitis is a good example. > > So the archetypes for problem, problem-diagnosis (specialised) and > differential diagnosis should meet these needs. > > Comments? > > Sam -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1999 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050428/2b2579c2/attachment.bin>
The Uncertainty Decision was: Dr R LONJON Confidence indicator !
The EHR is not invented to describe the real actual health status of the patient. It is there to document what clinicians deemed important to say ABOUT the health status of the patient. It always is an opinion of a professional about something. He, himself, always makes statements with varying degrees of certainty. Physicians are no gods that know everything. Readers of the statements made by others necessarily don't take everything for granted what other have stated. So again at the receiving side things are interpreted in varying degrees of certainty. Answering your question: > So back to the short answer above.is it really relevant to assert > ANY confidence factor in the EHR? > The answer is YES Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 27 Apr 2005, at 13:01, Arild Faxvaag wrote: > Tim Cook wrote: > While it might be an interesting exercise for us to record how > confident > a clinician was at the time of recording a diagnosis, it will have no > impact on the health care of that patient. If we were to do this would > we ask them to do so in 10% steps, 5% steps or .01% > steps? I assert that any one of these would seriously impact > the usability of an EHR in a negative manner and would result in the > clinician taking the option that presents the least liability on their > part. > > So back to the short answer above.is it really relevant to assert > ANY confidence factor in the EHR? > > > My opinion is that there indeed is highly relevant to assert a > confidence factor in the EHR. > > ln decision analysis one talks about treatment thresholds for > diagnostic uncertainity as "the probability of disease at which the > expected value of treatment and no treatment are exactly equal, and ne > ither option is clearly preferable." (Hunik and Glasziiou "Decision > making in health and biomedicine"). Factors influencing the treatment > threshold are the expected benefit and the expected harm of the > treatment. > Example: Treatment threshold is much lower for pneumonia (treatment: > penicillin) than for cancer of the left mamma (treatment: Mastectomy) > > Thus: How confident a clinician is at the time of recording a > diagnosis has high impact on the health care of that patient. > > Comments on this? > > regards, > Arild Faxvaag -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2656 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050428/c4d3ceb2/attachment.bin>
OIDs / II
Thomas, Will you bring this topic up in Berlin? Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 27 Apr 2005, at 13:48, Bert Verhees wrote: > Op woensdag 27 april 2005 11:21, schreef Thomas Beale: >> Bert Verhees wrote: >>>> 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, 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). >> >> as I have indicated before, I think that CEN needs the data type we >> added to openEHR - DV_INDENTIFIER, whose definition is below. I also > > It would help me a lot if CEN would take this instead of the original > ID, this > one has all what is suitable for my purpose > > Bert > >> don't agree that it is realistic to identify everything with OIDs. >> There >> are three reasons, the major one Bert has already given. >> >> 1. non-accessibility and/or performance of resolving engine >> 2. size of ids inside data, particularly data fragments that can never >> be sensibly accessed globally, only from within the context of some >> larger blob. E.g. it doesn't make sense to access a single ELEMENT in >> a >> CEN CLUSTER/ELEMENT tree, so why attach a 20 digit Oid to it? >> >> >> class DV_IDENTIFIER >> inherit >> DATA_VALUE >> >> feature -- Access >> >> issuer: STRING >> -- Issuing agency of these kind of ids >> >> id: STRING >> -- The identifier value. Often structured, according to >> the >> -- definition of the issuing authority?s rules. >> >> type: STRING >> -- The identifier type, such as ?prescription?, or ?SSN?. >> -- One day a controlled vocabulary might be possible for >> this. >> >> invariant >> issuer_valid: issuer /= Void and not issuer.is_empty >> id_valid: id /= Void and not id.is_empty >> type_valid: type /= Void and not type.is_empty >> >> end >> >> >> - thomas beale >> >> >> - >> 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 > -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2630 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050428/b29ecbf6/attachment.bin>
The Uncertainty Decision was: Dr R LONJON Confidence indicator !
Arild and Tim This is clearly an issue. In the CIP project the group wanted to be able to say that a diagnosis was a working diagnosis. We have archetyped a number of concepts that I think will enable the clinician to express these levels of uncertainty without resorting to confidence ratings on all entries in the record. Arild has shown that you could not possibly do a mastectomy without rating your certainty at 100% - or you will be sued. And not treating a pneumonia in a newborn with a certainty of only 20% will probably get you in trouble. These sort of explicit ratings are - in my opinion - very problematic. The solution lies in the recording constructs used for many years: 1. To express differential diagnoses (with or without probabilities) and to note key excluded diagnoses as well. 2. To express a diagnosis as a problem (such as lump in left breast) even if the likelihood of cancer is 100% clinically until the histology is returned. 3. To be able to label a diagnosis as a working diagnosis - ie it is likely enough to warrant the current management - but not certain. Appendicitis is a good example. So the archetypes for problem, problem-diagnosis (specialised) and differential diagnosis should meet these needs. Comments? Sam > Tim Cook wrote: > While it might be an interesting exercise for us to record how confident > a clinician was at the time of recording a diagnosis, it will have no > impact on the health care of that patient. If we were to do this would > we ask them to do so in 10% steps, 5% steps or .01% > steps? I assert that any one of these would seriously impact > the usability of an EHR in a negative manner and would result in the > clinician taking the option that presents the least liability on their > part. > > So back to the short answer above.is it really relevant to assert > ANY confidence factor in the EHR? > > > My opinion is that there indeed is highly relevant to assert a > confidence factor in the EHR. > > ln decision analysis one talks about treatment thresholds for diagnostic > uncertainity as "the probability of disease at which the expected value > of treatment and no treatment are exactly equal, and ne ither option is > clearly preferable." (Hunik and Glasziiou "Decision making in health and > biomedicine"). Factors influencing the treatment threshold are the > expected benefit and the expected harm of the treatment. > Example: Treatment threshold is much lower for pneumonia (treatment: > penicillin) than for cancer of the left mamma (treatment: Mastectomy) > > Thus: How confident a clinician is at the time of recording a diagnosis > has high impact on the health care of that patient. > > Comments on this? > > regards, > Arild Faxvaag - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
