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_7234Report.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)
