You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by "Wu, Stephen T., Ph.D." <Wu...@mayo.edu> on 2014/07/17 21:30:01 UTC
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 swu@apache.org or stw4@alumni.duke.edu for future correspondence!
Re: Type System updates
Posted by John Green <jo...@gmail.com>.
As a clinician Id really like to see the types that Melissa has elicited from physicians.
By the by: Id call apgar, or duke, or has bled score, or chads vasc, or childs criteria, or anything else like them risk classifiers or prognosticators or decision models or something like that (the line between is fuzzy sometimes).
JG
—
On Thu, Jul 17, 2014 at 3:30 PM, Wu, Stephen T., Ph.D.
<Wu...@mayo.edu> wrote:
> 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 swu@apache.org or stw4@alumni.duke.edu for future correspondence!
RE: Type System updates
Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
+1 on James' point(s) below
> -----Original Message-----
> From: Masanz, James J. [mailto:Masanz.James@mayo.edu]
> Sent: Monday, July 21, 2014 8:13 PM
> To: 'dev@ctakes.apache.org'
> Cc: 'melissa.tharp@me.com'; 'wendy.chapman@utah.edu';
> 'swu@apache.org'
> 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: dev@ctakes.apache.org
> Cc: melissa.tharp@me.com; wendy.chapman@utah.edu; swu@apache.org
> 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 swu@apache.org or stw4@alumni.duke.edu for future
> correspondence!
RE: Type System updates
Posted by "Masanz, James J." <Ma...@mayo.edu>.
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: dev@ctakes.apache.org
Cc: melissa.tharp@me.com; wendy.chapman@utah.edu; swu@apache.org
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 swu@apache.org or stw4@alumni.duke.edu for future correspondence!