Tom, Does leaving "the current DV_QUANTITY the way it is" include the ability to record "< 5 mmol/L" for example?
Heath -----Original Message----- From: [email protected] [mailto:owner-openehr-technical at openehr.org] On Behalf Of Thomas Beale Sent: Monday, 20 March 2006 5:30 AM To: openehr-technical at openehr.org Subject: Re: Pathology numeric values not supported in DV_Quantity Grahame Grieve wrote: > I agree with this - that's it good enough now. > > I think this thread is starting to talk about things which aren't > properly part of the data type, they are conceptual things about the > result values, and should be modelled explicitly in the archetypes. Grahame, is it your feeling that we need to have a better model of accuracy, i.e. more like the confidence interval idea? Or are we ok with what we have? My gut feeling is to leave the current DV_QUANTITY the way it is and consider either a) doing nothing - treat Tim's requirements as requirements not on primary data going into the EHR, but on generated data of the kind found in an epidemiological/statistical style of system or b) add a variant of DV_QUANTITY (probably a subtype) that does the full deal (and is convertible into a vanilla DV_QUANTITY). thoughts anyone? - thomas > > Grahame > > > > > Thomas Beale wrote: >> >> Sam would be better able to give an idea of all the health >> professionals who have been consulted, but certainly in Australia, >> Vince McCauley (a pathologist) has been extremely helpful on >> pathology result detail. Also, people like Heath Frankel and Grahame >> Grieve who have worked with HL7v2 messages for years have provided >> quite a lot of input on details (for example in Release 1.0, there is >> now a summary attribute for Historical data structures, directly due >> to Grahame's advice on the shape of lab data his software handles - >> see >> http://www.openehr.org/uml/Browsable/_9_0_76d0249_1109157527311_729550_7234R eport.html). >> >> >> Is it enough? At this stage I would be fairly confident that the >> models are good enough for most pathology data (certainly everything >> any of the docs working with openEHR has seen). Are they perfect? Of >> course not. We always need more input. The confidence level stuff >> implied by your requirements (let's treat them as epi/public health >> data requirements) would make things better; we just have to >> determine a) what scope of data they apply to (e.g. how much >> sophistication do we need in the EHR compared to say a dedicated data >> warehouse designed for statistical studies?) and b) how to add them >> to the current model in a way compatible with what is there. >> >> I think that he idea of a workshop is a good one; I would prefer to >> see clinical professionals here take up the suggestion and do >> something with it; I don't see these kinds of discussions as being IT >> driven - they are all about articulating requirements. >> >> - t >> >> >> Tim Churches wrote: >>> Thomas Beale wrote: >>> >>>> Tim Churches wrote: >>>> >>>>> >>>>> >>>>>> Tim, if the accuracy_is_percent attribute was upgraded to a coded >>>>>> value, could you suggest a set of meanings that would cover all >>>>>> the epi/PH needs? >>>>>> >>>>> You'll have to tell me what that would involve. A single coded value? >>>>> Upper and lower limits? Confidence level. Type of limit? >>>>> >>>> well, essentially what you are proposing >>> >>> Not proposing anything, I'm just asking the question "Have you >>> thought about this?" >>> >>> >>>> would require (let's not get >>>> too pure about how I use the word "accuracy" here for the moment): >>>> - lower accuracy limit: Real >>>> - upper accuracy limit: Real >>>> - accuracy limit type: coded term >>>> - confidence level (or this could be part of the previous coded >>>> attribute, since only a small number of confidence bands are used >>>> in practice aren't they?) >>>> >>>> Now, what we currently have is a set of general purpose quantity >>>> classes designed to enabled recording of any quantitative data we >>>> have come across so far. Between various MDs such as Sam, Vince and >>>> others, I think we have pathology covered from a practical point of >>>> view (well, we do once we get this <, >, etc thing sorted). >>>> >>> >>> Just curious: have you had much input from pathologists, >>> microbiologists and lab scientists? The more one talks to such >>> people, the more one discovers about the uncertainties inherent in >>> certain assay techniques, and the differences in the scalar (and >>> qualitative or Boolean) results produced by different assay kits and >>> different labs. >>> >>> Oh, there's another form of uncertainty which typically is of >>> relevance to Boolean/dichotomous results (positive/negative, >>> detected/not detected >>> etc) and that is the sensitivity and specificity of the test, or the >>> related quantities PPV (positive predictive value) and NPV. (Note to >>> computer scientists: "specificity" and "sensitivity" are cognate >>> with "precision" and "recall".) >>> >>> >>>> The real question is: what is the type & origin of data that need >>>> to represented in the more sophisticated way that we are now >>>> suggesting? Is it a different category of data? Should be leave the >>>> current DV_QUANTITY as is and add a new subtype? Or is it that we >>>> should consider a quantity with a 95% T-distribution confidence >>>> interval as a pretty normal thing? >>>> Should we then start considering the "simple" idea of a symmetric >>>> accuracy range (+/- xxx) as really just one specific type of a >>>> confidence interval (it might translate to something like 98% on a >>>> normal curve). In other words, should we generalise he "accuracy" >>>> notion >>>> into a "confidence interval" notion? >>>> >>> >>> I think that a one or two day workshop with a range of pathologists, >>> microbiologists, lab scientists, epidemiologists and statisticians >>> (and some clinicians and computer scientists, of course) would >>> suffice to come up with sensible answer to your question. I'd be >>> happy to participate and to suggest other participants. First half >>> day would need to be spent bringing everyone up to speed on openEHR >>> so they understand the nature of the question(s) to be addressed >>> (and a good means of spreading the openEHR gospel while you're at >>> it...). >>> >>> Might be possible to hold a cyber-workshop instead, via email or >>> real-time conferencing. The former would be much slower, of course. >>> >>> Tim C >>> >>> >>> >>> >> >> > -- ____________________________________________________________________________ _______ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org)
