Thursday, October 3, 2013

Plant Ontology and Ontology of Biomedical Investigations Admitted to OBO Foundry

The OBO Foundry has announced that it has admitted two additional ontologies to its membership.  Specifically, the Ontology of Biomedical Investigations (OBI) and the Plant Ontology (PO) met the standards of the OBO Foundry Editorial Working Group.  This move brings the number of Foundry ontologies to ten:

  1. chemical entities of biological interest
  2. biological process (gene ontology)
  3. cellular component (gene ontology)
  4. molecular function (gene ontology)
  5. protein ontology 
  6. phenotypic quality
  7. xenopus anatomy and development
  8. zebrafish anatomy and development
  9. plant ontology
  10. ontology of biomedical investigations
Per the announcement, ...OBI and PO have recently been reviewed by the OBO Foundry Editorial
Working Group, and reviewers found that they performed well when measured against accepted OBO Foundry Principles... Consequently, the Editorial WG recommended that PO and OBI be given full
member status as OBO Foundry Ontologies. This decision was ratified by the OBO Foundry Operations Committee.

Progress towards high-quality, peer-reviewed ontologies deemed acceptable for use in scientific and other endeavors thereby has taken a strong step forward.

Tuesday, May 14, 2013

Glossary designers cannot define components of glossaries

The International Organization for Standardization (ISO) is working on standard TS 17439 Health Informatics Common Glossary Metadata Repository and Maintenance Process, which aims to define the key components of glossaries in health informatics, so that all such glossaries will be interoperable.

However, the glossary people are having a hard time defining the key components of glossaries.

For example, the definition of 'term' is: The word or group of words being defined in the glossary.

This definition implies that terms do not exist unless they are in a glossary, which is clearly untrue.  Terms existed long before people put them in glossaries.


The definition of 'term ID' is:  A computer generated unique identifier for this instance of the term.

Why is it a necessary condition for term IDs that they be computer generated?  What if a human manually creates an identifier for a term?

Furthermore, what does it mean to have different "instances" of a term?  It appears that it means the appearance of a term in a particular health standards document.  So if the same term appears in two different standards with different definitions in those standards, it gets two identifiers.  But then how does one know that it's the same term?  Uniqueness of the string of characters that make it up?  But then how will one compare the definitions of 'arm pain' and 'pain in the arm'?

The definition of 'context' is: Specialisation context

That is like defining 'automobile' as 'blue automobile'.

Hopefully the glossary makers can get their own definitions right before this proposed standard is approved.

Tuesday, January 29, 2013

Cardiology Society (non) Defines Key Entities for Cardiovascular Care

The American College of Cardiology (ACC) and the American Heart Association (AHA) are to be lauded for their goal of creating standard definitions of key terms for use in collecting scientific data.

However, their execution is--quite frankly--abysmal.

Here are some definitions they generated:

SexIndicate the patient's sex at birth as either male or female. Choose 1 of the following: Male Female
Date of birthIndicate the patient's date of birth.


These are NOT definitions at all.  We have been misled.  These are instructions, however obvious.  What did the ACC and AHA think someone might do when confronted with a data entry form asking for the patient's sex and date of birth?

For real definitions of sex and date of birth, and a standard way of recording them that requires no special data machinery specific to demographics, see a paper by Hogan et al. from the 2011 International Conference on Biomedical Ontology.  These definitions have been captured in the Demographics Application Ontology, available here.

But since the real goal is to capture data elements specific to the field of cardiology, perhaps it is too unfair to criticize their efforts on demographics.   Cardiologists, after all, are more concerned with the heart than the rest of the person.

Alas, although they do move from instructions to definitions, their definitions are poor.  They are circular, meaning that they use the words in the term to define the term:

Prior anginaHistory of angina before the current admission. “Angina” refers to evidence or knowledge of symptoms before this acute event described as chest pain or pressure, jaw pain, arm pain, or other equivalent discomfort suggestive of cardiac ischemia. Indicate if angina existed >2 wk before admission and/or within 2 wk before admission.
Average number of episodes of angina in the prior weekAverage number of distinct episodes of anginal pain that occurred in the last week before hospital admission or this visit


Furthermore, what if the patient is not being admitted to the hospital?  According to this definition, a clinician should not record "prior angina" if the patient had a history of angina prior to a clinic or emergency department visit.

The definition of "angina", alas, although promising, is ruined by the prefix "evidence or knowledge of".   If there is no evidence or knowledge of Mr. Smith's angina (perhaps he has no memory of it due to some mental disorder such as dementia), it still exists.  It also conflicts with the subsequent instruction to record the existence (not knowledge or evidence) of angina.

Furthermore, it really defines two data elements, despite being listed as one.  We are told to record existence (not knowledge or evidence) of angina before 2 weeks prior to admission (data element #1) and the existence (not knowledge or evidence) of angina within 2 weeks prior to admission (data element #2).

Thus the data element "prior angina" is also ambiguous.

The circularity of the definition of "average number of episodes of angina in the prior week" is self evident.  Note that now we are told that by "admission", the ACC and AHA probably in fact do intend to refer to outpatient encounters as well as inpatient ones.

Perhaps they should have stopped to define "admission", "visit", etc. first?  Well, if they had, it wouldn't have taken them long.  They could have adopted the definitions of these terms provided by the Ontology for General Medical Science, available here.

So we see that persons who are experts in a particular field of study, although necessary to the process of defining the terms they use, are not sufficient.

They should have consulted a good ontologist!



Friday, October 21, 2011

Standardizing Ontology a Top Priority for NICHD

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.

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

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.

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.