OWL for Clinical Models

advertisement

KCOM

Kaiser Clinical Ontology Modeling

Peter Hendler and Michael Rossman

With some copyrighted material from

Matthew Horridge

Why Do This?

Last year we stressed the cost savings and simplicity added if different healthcare systems use a similar

(canonical) base model

This year we will show significant additional advantages if the model is created using Web Ontology Language

OWL and Description Logics (DL)

Quick Review Why

Canonical Models

4

Clinical Models

Why Do We Need Them?

 Electronic health care systems have evolved separately over the decades

 Most were created in isolation to solve one particular domain problem

(Pharmacy, Lab, Radiology, Clinical Notes, Scheduling, Billing, Admissions

Discharges and Transfers or Clinical Decision Support)

 As a result they all have their own models, and they can not share clinical data without complex expensive interfaces being built

5

Clinical Models

How Do These Systems Interoperate?

 All systems have a “data model” whether it is explicitly designed or is just the result of how the systems store data

 You must map the “data model” from one system to the “data model” for the other system if they are to share data.

 This requires too many expensive interfaces that goes up by N squared for

N systems.

 Every mapping or interface results in the loss of some meaning

6

Current Information Modeling in KP

Current state of information modeling at KP

 All applications are proprietary or legacy “ad hoc” “one-off”

 Each system has a unique persistence layer and data model

 Each new project generates a new relational database and new analytics

 Projects require the creation of unique interfaces with all the other programs and systems

 Interfacing and integrating programs and systems is both expensive and time consuming

Canonical Information Modeling implies

A standard representation of clinical data and the implied mapping back from each application to that (in common) representation

 Interoperability is inherently built into all clinical systems that are based on a canonical model

 At a minimum, if each legacy system can import and export the canonical data model, interfacing becomes much simpler (just N instead of

N(N-1)/2)

7

CANONICAL: conforming to a general rule or acceptable procedure

: orthodox [merriam-webster.com]

Why Do This in

OWL?

How are relevant research and outcome studies done now?

Some Example

Questions

Do patients on NSAIDs get more GI bleeds?

Do RA patients on biologic DMARDs get more non pulmonary TB?

Do RA patients on non biologic

DMARDs do as well as patients on any

DMARDs plus biologic DMARDS?

And how are these questions answered today?

By Manual Chart

Review Kat

This does not change with an Electronic

Health Record of unstructured data.

Whether paper or electronic, non structured text and non Ontological terminologies (like ICD) require individual reading and evaluation by a reviewer

By using OWL in

KCOM, these queries can be automated!

Outline

Three kinds of modeling kats

Why use SNOMED / CMT, and OWL?

What happens when you model the

HL7 RIM backbone in OWL?

Very Short Intro to OWL and Protege

Outline

How does KCOM address these problems?

The generalizable part of the model valid for all sub specialty domains

The specialized parts of the

Rheumatoid Arthritis Assessment Model

(RAAM)

The “Clinical Stories” used to create

KCOM

Walk through one semantic query

Three Kinds of

Modelers

This is often the cause of communication problems between IT people with different training backgrounds and different ways of looking at things.

19

Database Kitteh

Knows about RDBMS Kind of comfortable

20

8

Object Oriented Kat

Thinks in Unified Modeling Language (UML). Has lots of friends.

21

9

Ontology Kat

Is lonely, and misunderstood. But very powerful. He made

SNOMED

Why Use SNOMED /

CMT, OWL?

Medical Terminology

•SNOMED

•Ontology Description Logic

•Concerned with clinical meaning, not billing

•Fine grained enough to be clinically meaningful

•Can be used for Outcomes measurements

•Can be used by machines to make inferences

Inferences possible with SNOMED

•Strep throat is caused by streptococcus

•Pneumococcal pneumonia is caused by pneumococcus

•Streptococcus and pneumococcus are both sub types of gram positive cocci

•Therefore both pneumococcal pneumonia and strep throat are gram positive cocci infections.

First Example Question

Do patients on NSAIDs get more GI bleeds?

Without SNOMED or Ontology, clinical experts have to know the names and codes of all medications that are “a kind of” NSAID.

They have to know all the names of the hundreds of ICD9 codes that are “a kind of” GI bleed.

prone

Second Example Question

Do RA patients on biologic DMARDs get more non pulmonary TB?

How many ICD9/10 codes are “a kind of” RA

How many ICD9/10 codes are “a kind of”

DMARD?

How many ICD9/10 codes are “a kind of” non pulmonary TB?

Very difficult to do manually. Automatically done by SNOMED semantic search!

26

What happens when you model the HL7

RIM backbone in OWL?

4/8/2013 Kaiser Permanente © 2013

28

A Very Short Intro To

OWL and Protege

It’s all about triples

Protege

Three main views

Taxonomy: Only “Is A”

OWLViz: Only “Is A”

Definition: Where the triplets are defined

Taxonomy

View

OWL Viz View

Definition View

OWL is all about Triplets

Domain and Range

Subclasses

Define CheeseyPizza

Define MargheritaPizza

Define SohoPizza

A Stated Taxonomy View

A Stated OWL-Viz View

An Inferred OWL-Viz View

Stated and Inferred Taxonomies

How It Looks To

The Reasoner

IsA

How It Looks

To the Reasoner

IsA

They could be

Myocardial Infarction and Acute Myocardial

Infarction

The right side is the child of (subsumed by) the left side

Or they could be Pneumonitis and Infectious

Pneumonitis

To the Reasoner it doesn’t matter, as long as it can keep track of all the symbols.

It is manipulating symbols but the result makes perfect sense and results in clinically useful inferences

What Does RAAM

Model?

4/8/2013 Kaiser Permanente © 2013

48

What Goes In and Out of The Brain

Not trying to model the rules, or what happens in the brain of the expert who makes the decisions

Only modeling the data that a human expert clinician specialist brain needs to make it’s own assessment

Once the brain has made the assessment then we model the decision

This is “Decision Support” in a new way, no rules or suggested solutions, just support the decision maker with data

49

The Reasoner Completely Understands the Entire Model

Semantics

 Detects Inconsistencies

 Makes Logical Inferences

 Classifies Clinical Data Automatically

4/8/2013 Kaiser Permanente © 2013

50

The Reasoner Knows All About The Whole Model

4/8/2013 Kaiser Permanente © 2013

51

The generalizable part of the model valid for all sub specialty domains

Some example views into the model

4/8/2013 Kaiser Permanente © 2013

53

4/8/2013 Kaiser Permanente © 2013

54

4/8/2013 Kaiser Permanente © 2013

55

4/8/2013 Kaiser Permanente © 2013

56

4/8/2013 Kaiser Permanente © 2013

57

The Medical

Specialty Domain

Specific Part

4/8/2013 Kaiser Permanente © 2013

59

4/8/2013 Kaiser Permanente © 2013

60

4/8/2013 Kaiser Permanente © 2013

61

4/8/2013 Kaiser Permanente © 2013

62

4/8/2013 Kaiser Permanente © 2013

63

4/8/2013 Kaiser Permanente © 2013

64

How KCOM is bound to SNOMED

Individual Terms Bound to SNOMED-CT

4/8/2013 Kaiser Permanente © 2013

66

The Clinical Stories

Used to Design

KCOM

Based on clinical

cases

When KCOM was first designed, we took six examples of clinical notes from

Rheumatoid Arthritis Assessments

They covered various clinical scenarios

We will select six specific clinical statements from case number one and explore them in depth

We will look at them in English, UML and finally in KCOM OWL

4/8/2013 Kaiser Permanente © 2013

69

4/8/2013 Kaiser Permanente © 2013

70

4/8/2013 Kaiser Permanente © 2013

71

4/8/2013 Kaiser Permanente © 2013

72

4/8/2013 Kaiser Permanente © 2013

73

4/8/2013 Kaiser Permanente © 2013

74

4/8/2013 Kaiser Permanente © 2013

75

4/8/2013 Kaiser Permanente © 2013

76

4/8/2013 Kaiser Permanente © 2013

77

4/8/2013 Kaiser Permanente © 2013

78

4/8/2013 Kaiser Permanente © 2013

79

4/8/2013 Kaiser Permanente © 2013

80

4/8/2013 Kaiser Permanente © 2013

81

4/8/2013 Kaiser Permanente © 2013

82

4/8/2013 Kaiser Permanente © 2013

83

4/8/2013 Kaiser Permanente © 2013

84

4/8/2013 Kaiser Permanente © 2013

85

4/8/2013 Kaiser Permanente © 2013

86

4/8/2013 Kaiser Permanente © 2013

87

And One Semantic

Query Example

2

Compare the number of gastrointestinal bleeds in RA patients in the following groups.

Those who have and have not taken NSAIDs

Break this up into steps.

First find Patients with RA

PersonAsPatient and subjectOf Observation hasAssociatedFinding Rheumatoid Arthritis

(we will be using this basic query in all the other examples)

Now using this limited cohort of RA patients continue to query as follows to find the sub groups.

Now we find two sub groups, those who are not on NSAIDs and those that are.

(we can do this for current use or past use which ever we choose)

PersonAsPatient and subjectOf Observation has

MedicationAdministration has AssociatedMedication some

NSAID.

(note the subsumption here is very useful. Otherwise you have to accumulate all the meds that are NSAIDs with the help of a clinical/pharmacy expert. In the KCOM case this clinical knowledge is part of the model itself)

PersonAsPatient and subjectOf Observation has

MedicationAdministration has AssociatedMedication

ONLY NOT NSAID (we will not explain the difference between “some” and “only” but this query gets those NOT on any kind of NSAID .

Now we have these two groups and we need to find in each one who has had GI bleed. The ICD9 or ICD10 has many different diagnosis that are all some kind of GI bleed.

Not being able to use SNOMED subsumption is a fatal drawback. Because we are using SNOMED and because we are using OWL in our base clinical model we can simplify this complex query into.

PersonAsPatient and SubjectOf Observation hasAssociatedFinding some <<bleeding and has finding site gastro-intestinal structure>>

(the latter part is a post coordinated SNOMED expression I used just for demonstration We could also use instead the pre-defined SNOMED term

74474003:GastroIntestinal Hemorrhage (disorder)

It is important to point out. There are too many ICD9 and ICD10 codes that are all a kind of

“Gastrointestinal Hemorrhage” and unless you happen to know all of them, you will miss some patients.

This SNOMED Description Logic Subsumption query will catch all of them even if you don’t know what they are called. Even a clinical expert could not be expected to recall every possible kind of ICD9 or 10 term that is some kind of gastrointestinal bleed.

Conclusions

Last year we stressed the advantages

(in time money and simplicity) of using standard (canonical) models to integrate clinical systems

Conclusions

This year we show that by using models based on Description Logic (OWL) and

SNOMED we are able to use Semantic

Searching to automate important and complex queries that would otherwise need manual chart reviewers and take much more time and expense.

Does Ontology Kat

Work Well With

OWL?

Abbreviations

RAAM: Rheumatoid Arthritis Assessment Model

RDBMS: Relational DataBase Management System

OO: Object Oriented

KCOM: Kaiser Clinical Ontology/OWL Model

DMARD: Disease Modifying AntiRheumatic Drug

NSAID: Non Steroidal AntiInflammatory Drug

OWL: Web Ontology Language

DL: Description Logics

Download