11 Feb 2014

See also: IRC log


Kerstin_Forsberg, ericP, +1.469.226.aaaa, [IPcaller], Mike_Denny


ontology review

Claude: reviewed josh's FHIR and O-RIM with an eye towards using it for clinical decision support
... wanted what could be leveraged for use in a CDS ontology
... RIM's need for interop lead to a closed model with many constraints.
... O-RIM's terminology is particular to RIM.
... I had planned on an ontology designed for a more open world
... using SKOS/DC rather than RIM
... the philosophy is a bit different:
... .. getting interop in key aspects of use cases leads to a very controlled expression which won't meet arbitrary new use cases.
... .. alternatively, design with a set of principles which can allow extenders to get interop when possible but still extend in new ways when needed
... O-RIM has lots of classes which are designed by intersection.

ericP: right, RIM's real ontology code is in implementation guidelines which re-use the six for classes and the e.g. source/target constraints for particular ActRelationship codes
... alternative, e.g. frequency superProperty which is partitioned into basically incomaptible specialized frequencies

Claude: for example, you could have an obs with multiple codes, but that confuses interop

ericP: Standards are intended to reduce people's choices. The strength of the semantic web is that there is both a social and technical aspect to it. The technical aspect permits non-ambiguity. The social aspect allows one to leverage what exists on the web to develop their own ontologies.

development strategy

ericP: The standard is released to meet some use cases but this has a very long tail. Because standards are slow to develop, you often take too long to get something in people's hands or the standard does not meet anyone's needs. By developing an ontology that is more open world, you can better address the long tail but you are less able to constrain this ontology.

E.g., extensions of SKOS vocabularies for terminology. The problem with this approach is that it can become chaotic with people creating concepts that can no longer properly support inferencing or that are semantically inaccurate.

Need some professional governance to ensure that there is some order in this process. There are systems that exist to support this. For instance, Web Protege, Drupal, etc....

That is, encourage discussion among participants to support proper review of proposed concepts and relationships.

To develop a CDS ontology could take many years, so an open world with crowd sourcing and review may reduce the chaos in this process.

This may allow more flexibility in its development. However, some governance needs to be in place.

E.g., someone proposes a concept. It is reviewed to ensure (1) it does not already exist, (2) it is semantically 'correct', (3) it is placed in its proper place in the hierarchy.

Need to be concerned with the following:

You may propose concepts but these need to be reviewed

Write deviations from core or everyone collaborates to form ontology

This requires sufficient expertise among the reviewer to ensure that the ontology is sound.

That the ontology is inferenceable

Group collaborates to define the ontology

Another group (the 'board') validates and 'approves' the changes.

UMLS has website that allows folks to propose concepts/synonyms and then these are reviewed and possibly incorporated.

UMLS is versioned and different versions may hold a different set of concepts.

Problem arises during splitting of concepts.

It forces folks to identify where concept is used and which new one should be used if they decide to adopt this version of the terminology.

Claude: if you look at HL7's coded value, you have:

rim:Act.code [

    hl7:coding [ dt:CDCoding.code "48765-2" ; dt:CDCoding.codeSystem "2.16.840.1.113883.6.1" ;
                 dt:CDCoding.displayName "ALLERGIES, ADVERSE REACTIONS, ALERTS" ; dt:CDCoding.codeSystemName "LOINC" ]

see example from C-CDA in O-RIM

... this could easily be represented as an extension to skos
... the disease hierarchy in SNOMED has e.g. broader, narrower, related
... (potential transitive)
... emphasema narrowerThan lungDisease narrowerThan disease.
... vs. emphasema relatedTo smoking
... so use skos as a core with a set of extensions validated by domain experts as being correct and meeting valuable use cases [bang for the buck]
... so when you working with this, you're extending a solid, well-thought-out core

kirsten: important to work toghether with existing standards orgs
... in bioportal, we're working with an old version of MeDRA because we didn't push the skos back

Some ontologies were very pure but do not meet any use cases. More concrete ontologies that meet particular use cases may thus be favored.

Some ontologies are more arcane but they are arcane because they needed to solve a particular challenge that a cleaner ontology may not have anticipated.

The 'agile' vs 'waterfall' - build around the use cases vs build to meet a theoretical optimum but without field validation.

Core ontology for key clinical concepts such as observation, procedure, etc...

Data types

Some key libraries

At the bottom are ontologies for each of the therapeutic areas

They are basically subclasses of observations, assessments, etc... but they are particular to the domain - e.g., more 'Detailed Clinical Models'

They reside in the therapeutic ontology

Some of these concepts may be leveraged by other ontologies for different purposes

This process may break things as concepts are moved from one ontology to another but allows a healthy 'refactoring' over time.

Progressive elaboration could really benefit a CDS ontology.

Need to write documentation for our implementation and have people reuse ontology and governance model. This will encourage FDA to enhance their ontologies with additional Therapeutic Areas.

<mike_denny> Request to group members: I am preparing a rationale statement for including RDF/OWL provisions in a healthcare information system. I am trying to pull together a fairly exhaustive list of where RDF and OWL are being used today in healthcare related applications, tools, services, research initiatives, or other resources. If you aware of any listings or specific examples that you can point me toward, please forward to msdenny@mitre.org or the HCLS fo[CUT]

<ericP> http://code.google.com/p/cpr-ontology/

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-02-14 09:58:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: Claude
Inferring Scribes: Claude
Default Present: Kerstin_Forsberg, ericP, +1.469.226.aaaa, [IPcaller], Mike_Denny
Present: Kerstin_Forsberg ericP +1.469.226.aaaa [IPcaller] Mike_Denny

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 11 Feb 2014
Guessing minutes URL: http://www.w3.org/2014/02/11-hcls-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]