Think the background of our discussions is about CLASSfying. Sent from my iPad
On Jun 21, 2012, at 8:08 PM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 21/06/2012 19:07, Gerard Freriks wrote: >> >>> So to summarise, it came down to finding categories on which health >>> information data structures - i.e. information models - could be based that >>> would work reliably for most if not all of medicine. Now, having used these >>> categories for some years, it turns out that they are remarkably stable. I >>> know that the grey-zone debate on Observation/Evaluation will continue for >>> ever, but if one steps back for a second, what you see is that for most >>> types of clinical data, it is obvious which category to use. Most of the >>> archetypes for these types are not really in question. Further, noone has >>> identified (to my knowledge) a strong contender for any new kind of >>> category (excepting for sub-categories of AdminEntry, which will probably >>> appear one day). >> >> On the contrary, in spite of your claimed years of experience, I have my >> claim to experience both in the openEHR world and that of the EN13606 >> association and this experience shows that they way users use the >> definitions in openEHR give rise to problems for the users. I agree that >> nobody will er a Blood Sugar Measurement result as an Evaluation or >> Instruction or Action. >> In literature I have seen many wrong annotations because of problematic and >> unclear definitions in the real of openEHR. >> Why are we having this discussion if there were no problems what so ever? > > Not my personal experience, I mean the experience of deployed openEHR systems > around the world. In a sense there is no difference between openEHR and 13606 > - the same problem has to be solved: what data structures are used to > represent various clinical information? It's just that 13606, being designed > solely for haphazard and unknowable (in advance) legacy data doesn't provide > any specific Entry data structures. OpenEHR provides the GenericEntry for > that case, but also specific types of Entry for data (legacy or newly > created) whose structure is known. > > There are various advantages of these data structures: > a) you can actually build software that can process the data properly. When > everything is a tree, you have to write your own private model for that - > everyone re-invents a basic wheel, and those software components are not > generally re-usable with different data. > b) You can reliably query, because you know where things are. When you > aggregate huge amounts of clinical data from numerous sources into > patient-centric health records, being able to find Event origin times, Action > descriptions, protocol data and so on is worth a lot. > c) you have a standard representation for some key patterns, which means > archetypes based on those patterns will be the same in those key features, > which provides a level of built-in standardisation for archetypes, for those > features. > It is not that there are no problems; the problems are to do with, in some > cases, knowing what Entry type to use (since you appear to agree with the use > of the specialised Entry types, this problem is the same in 13606). The > answer has been confused somewhat by us being too purist and trying to > completely equate the data structures with the intended ontological > categories - as Ian McNicoll has said many times. I have always said, what's > the problem? But as soon as a clinical modeller comes up with an example like > some kind of summary, there is a long debate. That's all that is happening > here. > There is nothing basically wrong with the existing Entry types, or at least > no evidence of it that I have seen (and a lot of evidence to the contrary). > What is potentially not quite right is our understanding of how to use them > in all cases. We need to develop better descriptions of which types to use > for the more recently apprehended examples like 'clinical summary' and > various types of lab result which have 'interpretations' included. > Interestingly, in the openEHR system implementation environments I know of, > these debates are short and sweet. The choice is made, the archetypes, > template and software are built and deployed. > - thomas > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20120621/84e33164/attachment.html>
