+1 on James' point(s) below
> -----Original Message----- > From: Masanz, James J. [mailto:[email protected]] > Sent: Monday, July 21, 2014 8:13 PM > To: '[email protected]' > Cc: '[email protected]'; '[email protected]'; > '[email protected]' > Subject: RE: Type System updates > > 1) It's not clear if you are saying a downstream user needs some of those > elements, or is just pointing out the discrepancy. If the elements are > needed, then I suggest opening a JIRA item listing what it needed and the > community would decide how to handle that. As it is we have some > elements defined that we don't have a component or algorithm to set/fill-in > and then people wonder why they are there. So I suggest we don't add > things until they are needed/requested for a specific use. > > 2) If a named entity doesn't fit into existing types, and there is code to > populate such a type(s), I think we should add a new type (once we > understand it fully). > > II & III) I think you should go for it. > > > -----Original Message----- > From: Wu, Stephen T., Ph.D. > Sent: Thursday, July 17, 2014 2:30 PM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Type System updates > > The type system needs some updating. Here are some reasons: > > 1. The refsem and textsem namespaces were created to reflect the > Secondary Use Clinical Element Models (CEMs) defined in the SHARP project. > However, later modification to those models are not reflected in the cTAKES > type system. > > 2. Wendy Chapman, Melissa Tharp, et al (CC'ed here) have done some > quantitative studies showing that physicians do not easily categorize their > named entities of interest into cTAKES types. For example, even if we could > pick up values (as James mentioned, we don't pick up many), how would you > categorize an Apgar score? That kind of thing is not exactly a Procedure, > Lab, > or SignSymptom -- at least, physicians don't seem to think so. > > 3. We have been using the type system for a while and it might be due time > for some ground-up modifications (though I do think this is more of an > ongoing task). > > > The courses of action we can take are aligned somewhat to these different > reasons. > > I. Try to reconcile the CEMs with the Type System. Here is a diff, put > together by Melissa Tharp: > http://bit.ly/WkqCPa > I feel like this will be quite complicated, especially given the differences > between Assertion and SignSymptom. Also, if we add everything from the > CEMs, that significantly adds to the Modifiers that we have to create to > house those types. Each attribute of a CEM may require its own processing > and evaluation (i.e., you might need a dedicated analysis engine just to > discover DiseaseDisorder:severity), but in practice there may be too many > options of types and attributes. > > II. Follow the work being done on physician-validated types. Melissa might > be able to put together another document with the differences between > their resulting types (Schema Ontology) and our Type System. We could > then use this to update the types with what physicians are actually looking > for. > > III. Solicit user/developer-initiated changes, to be made at the same time as > one or both of the above. > > What does everyone think? > > stephen > P.S. Please use [email protected] or [email protected] for future > correspondence!
