LexGrid Philosophy, Model and Interfaces Harold R Solbrig Division of Biomedical Statistics and Informatics Mayo Clinic

05/01/2009LexGrid - Philosophy and Model2 Outline Why the LexGrid model was created LexGrid approach and principles Key aspects of the LexGrid model

05/01/2009LexGrid - Philosophy and Model3 Why LexGrid? The situation in the late 1990’s: Multiple “terminologies” available SNOMED-3 and SNOMED-RT READ Codes HCDA (ICD-8 w/ Mayo Extensions) ICD-9-CM...

05/01/2009LexGrid - Philosophy and Model4 Why LexGrid? The situation in the late 1990’s: DL was on the horizon SNOMED-RT GALEN DAML+OIL beginning to emerge

05/01/2009LexGrid - Philosophy and Model5 Why LexGrid? Mayo Health Sciences Research Multiple experiments and projects involving NLP, semi-automated record coding and classification, terminology-driven record retrieval, coded medical records, etc.

05/01/2009LexGrid - Philosophy and Model6 Why LexGrid? Mayo recognized the need for re-use Terminologies have common characteristics Software should be reusable Search and indexing Query Tree traversal...

05/01/2009LexGrid - Philosophy and Model7 Why LexGrid? Part of the solution was the service oriented model: Aka “Breadboard” API specifications (OMG’s LQS was primary example)

05/01/2009LexGrid - Philosophy and Model8 Why LexGrid? Service Oriented Model: Application performs search against server using a SNOMED-RT database. Referred to as API specification. An Interface specification may include a server connected to a collection of ICD9CM tables. Application Find designations matching “Myocard Infarct” Client Server SNOMED-RT ICD-9-CM Server API Specification Interface Specification

05/01/2009LexGrid - Philosophy and Model9 Why LexGrid? API/Interface Specification Provides a common semantics What is a “definition”, “designation”, “relationship”,... Provides a common interface Allows implementation to be specific to the terminology...

05/01/2009LexGrid - Philosophy and Model10 Single databases load by an import module. Semantic mapping occurs within the individual server. Server SNOMED-RT ICD-9-CM Import... Import Semantic Mapping Semantic Mapping Semantic Mapping Why LexGrid API/Interface Specification

05/01/2009LexGrid - Philosophy and Model11 Why LexGrid? Harmonization on the model level There are three different import modules, but they now connect to the common data model. The semantic mapping occurs during the import rather than within the server. CommonServer Common Data Model Import Semantic Mapping Semantic Mapping Semantic Mapping

05/01/2009LexGrid - Philosophy and Model12 Why LexGrid? LexGrid: A Common Terminology Data Model Descriptive not Prescriptive

05/01/2009LexGrid - Philosophy and Model13 LexGrid Design Principles Must span spectrum of “terminology” Code/value lists Thesauri (BT/NT) Classification Schemes Ontology & DL

05/01/2009LexGrid - Philosophy and Model14 LexGrid Design Principles Must provide common semantics for elements that are used in service API: (Textual) Definitions Designations Comments Language / context / character set Hierarchies Relationships

05/01/2009LexGrid - Philosophy and Model15 LexGrid Design Principles Must support non-API components as tag/value pairs. Must map ALL internal semantics to external (terminological) definitions. A property is useless if you don’t know the meaning of the tag A relation is useless if you don’t know its definition

05/01/2009LexGrid - Philosophy and Model16 LexGrid Design Principles Focus should be in information model vs. implementation: Originally implemented in LDAP XML Schema Model (Multiple) SQL Renderings to meet different user requirements Both Castor and Eclipse EMF renderings

05/01/2009LexGrid - Philosophy and Model17 LexGrid Model Service Layer becomes secondary! The common data model where semantic mapping occurs in the import modules. Additional services can also run off of the same data model, such as REST (read) or Hybernate Common Data Model Import Services Import Semantic Mapping Semantic Mapping Service Import Semantic Mapping REST (read) Hybernate...

05/01/2009LexGrid - Philosophy and Model18 LexGrid Key Components Key components coding schemes include code and associations. Code for definitions, designations, comments and instructions. All of which have defined properties. Associations include Relation, Source and Target. Properties Coding Scheme Code Definitions Designations Comments Instructions Associations Relation Source Target 1..*

05/01/2009LexGrid - Philosophy and Model19 LexGrid Key Components Mappings supportedCodingScheme supportedSource supportedProperty supportedAssociation supportedPropertyQualifier..... Transform a “local name” to a URI supportedAssociation localId=“hasPart” URI=“

05/01/2009LexGrid - Philosophy and Model20 LexGrid Future and Next Steps Many loaders, interfaces available today OBO, OWL, RDF, UMLS, CSV, Ontylog, custom... Several service API’s and implementations CTS, LexEVS (core of caBIG), LexWiki (sort of “implementation”)

05/01/2009LexGrid - Philosophy and Model21 LexGrid Future and Next Steps LexRDF OWL (2.0), DC, FOAF, SKOS (2008), RDF, RDFS, RO (to an extent) together now provide a reasonable overlay to LexGrid semantics Next step is to absorb and integrate Mappings can now reference these RDF import/export form that maintains model while using appropriate tags

05/01/2009LexGrid - Philosophy and Model22 More Information