The Eunice Kennedy Shriver National Institute for Child Health and Human Development held a series of "vision workshops" to create its vision for the next decade.
In a slide deck here (warning: PDF), the number one recommendation under the heading of "Transdisciplinary Science" is ...Standardize ontology, nomenclature, and data standards across disciplines.
The Director of NICHD, Dr. Alan Guttmacher, reitierated that recommendation today in a presentation to the Clinical and Translational Science Award Consortium Child Health Oversight Committee (CC-CHOC). The CC-CHOC meeting had a theme of "Quality Data from Pediatric Trials".
Speakers throughout the day emphasized the need for development and use of standards for collection of data in pediatric research.
Friday, October 21, 2011
Thursday, July 28, 2011
Workshop and Tutorial Summary
I attended the Representing Adverse Events Workshop, and presented as part of the Improving Structured EHR Data Tutorial.
The Adverse Events Workshop confronted the issue of what exactly an adverse event is. A diversity of viewpoints frustrated attempts to reach consensus. The need for an adverse events ontology was called into question by some participants (and one non-participant with whom I discussed the issue afterwards). The concern is that various symptoms and diseases will be duplicated. For example, "fever" vs. "fever adverse event" and "rash" vs. "rash adverse event".
The outcome was an agreement to review use cases and to create a Google Group where participants can post links to their ontologies with requests for feedback. One participant took the action item of reviewing various artifacts (ontology and otherwise) that give definitions of 'adverse event' to look for commonalities.
The Improving Structured EHR Data Tutorial was given by Werner Ceusters and myself. As one of the instructors, I do not want to overstate the success of the tutorial, but there were excellent discussions about Referent Tracking and the advantages it has for making EHR data unambiguous. At least one participant approached me to express her appreciation for the potential of Referent Tracking, and her willingness to collaborate on projects in the future.
The hard work of improving our ability to leverage information to accelerate improvements in the quality and efficiency of biomedical research and patient care continues...
The Adverse Events Workshop confronted the issue of what exactly an adverse event is. A diversity of viewpoints frustrated attempts to reach consensus. The need for an adverse events ontology was called into question by some participants (and one non-participant with whom I discussed the issue afterwards). The concern is that various symptoms and diseases will be duplicated. For example, "fever" vs. "fever adverse event" and "rash" vs. "rash adverse event".
The outcome was an agreement to review use cases and to create a Google Group where participants can post links to their ontologies with requests for feedback. One participant took the action item of reviewing various artifacts (ontology and otherwise) that give definitions of 'adverse event' to look for commonalities.
The Improving Structured EHR Data Tutorial was given by Werner Ceusters and myself. As one of the instructors, I do not want to overstate the success of the tutorial, but there were excellent discussions about Referent Tracking and the advantages it has for making EHR data unambiguous. At least one participant approached me to express her appreciation for the potential of Referent Tracking, and her willingness to collaborate on projects in the future.
The hard work of improving our ability to leverage information to accelerate improvements in the quality and efficiency of biomedical research and patient care continues...
Monday, July 25, 2011
On the eve of ICBO 2011
I am here in Buffalo on the eve of the International Conference on Biomedical Ontology 2011. The conference begins with workshops and tutorials on Tuesday and Wednesday, followed by the 3-day conference program on Thursday, Friday, and Saturday.
The conference web site is here.
I will be attending the Representing Adverse Events Workshop tomorrow, then participating in a more meaningful way in the Improving Structured EHR Data Tutorial on Wednesday morning.
Over the next few days, it is my intent to post summaries of the best and worst of this year's ICBO, as I did at the last ICBO in 2009.
The conference web site is here.
I will be attending the Representing Adverse Events Workshop tomorrow, then participating in a more meaningful way in the Improving Structured EHR Data Tutorial on Wednesday morning.
Over the next few days, it is my intent to post summaries of the best and worst of this year's ICBO, as I did at the last ICBO in 2009.
Friday, April 29, 2011
ISO TR 12310 Draft Standard - Problems and Issues
A draft of the ISO TR 12310 standard came across our desks in the last day or two, and we were surprised at the substantial problems that exist in its fundamental components. The title of the standard is "Health informatics — Principles and guidelines for the measurement of conformance in the implementation of terminological systems".
First, it defines a concept as "A concept is a single mental representation of some real or abstract thing."
This definition is problematic, because never in the history of terminological systems has anyone elucidated a theory of a basic unit of mental representation. What is a single mental representation? Or a unit of thought (as concept has also been defined)?
If I'm thinking of a car, is that a unit of thought? What if I'm thinking about a particular red, C-class Mercedes Benz with a particular Vehicle Identification Number? Or what if I'm just thinking about red, C-class Mercedes owned by stock brokers and that need new brakes and on which a tree fell during a Spring storm, in general? How many unique mental representations are there? One, two, three? How do we count unique ideas and single mental representations?
This question is not trivial, as the answer determines what concept representations we are permitted to have. Historically, the answer has been that anything anyone wants to put in the system is allowable. For a real-world example, consider the following "concept" from SNOMED CT: Family history of myocardial infarct in first degree female relative less than 65 years of age (situation).
The draft standard then goes on to say: "Concepts are should be unique within a code system." The grammatical problem aside, the standard is now engaged in use-mention confusion. For your mental representations are not part of any code system! The standard is using the word concept for both representations of concepts and concepts (themselves mental representations).
The draft standard then goes on to say: "A concept representation is a mechanism by which the system can express a concept." So it should be concept representations that are unique within a code system, not concepts.
But then the standard says: "Most code systems support multiple representations for each concept, sometimes even multiple representations of a given type."
How do code systems support interoperability, then?
Next, we are told that a "Concept id" is "A concept representation that is unique within the code system and that is used internally by the code system when referencing concepts."
Does that mean we cannot use concept ids outside the code system, either because it's impossible or disallowed? Surely some software applications are using SNOMED CT concept ids external to SNOMED CT itself? Are they out of conformance?
And that covers just pages 1 and 2.
First, it defines a concept as "A concept is a single mental representation of some real or abstract thing."
This definition is problematic, because never in the history of terminological systems has anyone elucidated a theory of a basic unit of mental representation. What is a single mental representation? Or a unit of thought (as concept has also been defined)?
If I'm thinking of a car, is that a unit of thought? What if I'm thinking about a particular red, C-class Mercedes Benz with a particular Vehicle Identification Number? Or what if I'm just thinking about red, C-class Mercedes owned by stock brokers and that need new brakes and on which a tree fell during a Spring storm, in general? How many unique mental representations are there? One, two, three? How do we count unique ideas and single mental representations?
This question is not trivial, as the answer determines what concept representations we are permitted to have. Historically, the answer has been that anything anyone wants to put in the system is allowable. For a real-world example, consider the following "concept" from SNOMED CT: Family history of myocardial infarct in first degree female relative less than 65 years of age (situation).
The draft standard then goes on to say: "Concepts are should be unique within a code system." The grammatical problem aside, the standard is now engaged in use-mention confusion. For your mental representations are not part of any code system! The standard is using the word concept for both representations of concepts and concepts (themselves mental representations).
The draft standard then goes on to say: "A concept representation is a mechanism by which the system can express a concept." So it should be concept representations that are unique within a code system, not concepts.
But then the standard says: "Most code systems support multiple representations for each concept, sometimes even multiple representations of a given type."
How do code systems support interoperability, then?
Next, we are told that a "Concept id" is "A concept representation that is unique within the code system and that is used internally by the code system when referencing concepts."
Does that mean we cannot use concept ids outside the code system, either because it's impossible or disallowed? Surely some software applications are using SNOMED CT concept ids external to SNOMED CT itself? Are they out of conformance?
And that covers just pages 1 and 2.
Subscribe to:
Posts (Atom)
Posts
