Presentation on theme: "KCOM Kaiser Clinical Ontology Modeling"— Presentation transcript:
1KCOM Kaiser Clinical Ontology Modeling Peter Hendler and Michael RossmanWith some copyrighted material fromMatthew Horridge
2Why Do This?Last year we stressed the cost savings and simplicity added if different healthcare systems use a similar (canonical) base modelThis year we will show significant additional advantages if the model is created using Web Ontology Language OWL and Description Logics (DL)
4Clinical Models Why Do We Need Them? Electronic health care systems have evolved separately over the decadesMost 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
5Clinical 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 dataYou 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
6Current Information Modeling in KP Current state of information modeling at KPAll applications are proprietary or legacy “ad hoc” “one-off”Each system has a unique persistence layer and data modelEach new project generates a new relational database and new analyticsProjects require the creation of unique interfaces with all the other programs and systemsInterfacing and integrating programs and systems is both expensive and time consuming
7Canonical Information Modeling implies A standard representation of clinical data and the implied mapping back from each application to that (in common) representationInteroperability is inherently built into all clinical systems that are based on a canonical modelAt 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)CANONICAL: conforming to a general rule or acceptable procedure : orthodox [merriam-webster.com]
8Why Do This in OWL?How are relevant research and outcome studies done now?
9Some 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?
12By 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
13By using OWL in KCOM, these queries can be automated!
15Outline 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
16Outline How does KCOM address these problems? The generalizable part of the model valid for all sub specialty domainsThe specialized parts of the Rheumatoid Arthritis Assessment Model (RAAM)The “Clinical Stories” used to create KCOMWalk through one semantic query
23Medical Terminology SNOMED Ontology Description Logic Concerned with clinical meaning, not billingFine grained enough to be clinically meaningfulCan be used for Outcomes measurementsCan be used by machines to make inferences
24Inferences possible with SNOMED Strep throat is caused by streptococcusPneumococcal pneumonia is caused by pneumococcusStreptococcus and pneumococcus are both sub types of gram positive cocciTherefore both pneumococcal pneumonia and strep throat are gram positive cocci infections.
25First 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.This requires Chart Review Kat and is error prone
26Second Example Question Do RA patients on biologic DMARDs get more non pulmonary TB?How many ICD9/10 codes are “a kind of” RAHow 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!
27What happens when you model the HL7 RIM backbone in OWL?
46They could be Myocardial Infarction and Acute Myocardial Infarction The right side is the child of (subsumed by) the left sideOr they could be Pneumonitis and Infectious PneumonitisTo 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 inferences46
49What 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 decisionsOnly modeling the data that a human expert clinician specialist brain needs to make it’s own assessmentOnce the brain has made the assessment then we model the decisionThis is “Decision Support” in a new way, no rules or suggested solutions, just support the decision maker with data
68Based on clinical cases When KCOM was first designed, we took six examples of clinical notes from Rheumatoid Arthritis AssessmentsThey covered various clinical scenariosWe will select six specific clinical statements from case number one and explore them in depthWe will look at them in English, UML and finally in KCOM OWL
892Compare the number of gastrointestinal bleeds in RA patients in the following groups.Those who have and have not taken NSAIDs
90Break this up into steps. First find Patients with RAPersonAsPatient 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.
91Now 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)
92PersonAsPatient 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.
93PersonAsPatient 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 :GastroIntestinal Hemorrhage (disorder)
94It is important to point out 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.
95ConclusionsLast year we stressed the advantages (in time money and simplicity) of using standard (canonical) models to integrate clinical systems
96ConclusionsThis 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.