Knowledge in Medilink: Guidelines, Protocols and CBR

1
Knowledge in Medilink Guidelines, Protocols and
CBR Lucy Hederman1 Kudakwashe Dube2 Padraig
Cunningham1 1Dept. of Computer Science, Trinity
College Dublin 2Dept. of Computer Science, DIT
(Kevin St.)
2
Outline

• Knowledge in Medilink
• Guideline Knowledge
• As workflow process
• Protocol knowledge
• As ECA rules
• Diagnostic knowledge
• Implicit in a case base

3
Protocols, plans and logs
Order
Prescrib
Protocol Automation
CBR
Schedul
LIS
Care Process Knowledge
Synapses
Care Process Engine
PAS
Process Exec. Log
Other Pat. DB
Report
MODEL
SIMUL
Analyse
Other decision support components

invocation
data flow
4
Medilink Components

• Synapses
• Care process engine
• Implements guidelines
• Sequences invocations to other components
• Protocol automation
• Case-based Reasoning (CBR)
• Modelling
• Simulation

5
Knowledge in Medilink

• Guideline/protocol knowledge explicit
• As process models for enactment in workflow
  engine
• As ECA rules in an active database
• Mathematical models
• Simulation models
• Knowledge captured in past cases, realised by CBR.

See next session
6
Guideline knowledge

• Clinical practice guidelines are
• Recommended strategies for managing healthcare in
  specific clinical circumstances.
• Evidence-based best practice
• Range from procedural/algorithmic guidelines to
  declarative ones.
• Our approach is directed at the former.

7
Guideline Tasks(Tu and Musen)

• Make decisions
• Sequence actions
• Set goals
• Maintain BP lt 130/85 for DM patients
• Interpret data
• Severity of asthma from freq, lung function
• Refine actions
• Operationalise an abstract intervention

8
Problems with Guidelines

• Largely text-based to date.
• Any flowcharts are usually ambiguous.
• Poorly and slowly adopted.
• Need guideline-based computersied decision
  support at the point of care

9
Guidelines as Processes

• View a clinical practice guideline as a
  (business) process model
• Encode the guideline as a (business) process
• Use a process engine to enact (automate) the
  guideline process

10
Motivation

• Huge activity and effort in business process
  modelling and automation.
• Lets not reinvent the wheel
• Use mainstream technology
• UML for guideline modelling
• Workflow engines for automation
• and benefit from ever-improving tools.

11
Protocols, plans and logs
Order
Prescrib
Protocol Automation
CBR
Schedul
LIS
Care Process Knowledge
Synapses
Care Process Engine
PAS
Process Exec. Log
Other Pat. DB
Report
MODEL
SIMUL
Analyse
Other decision support components

12
Medilink Component Interaction

• Synapses feeds data from DBs and components that
  provide patient data to components that need
  data.
• Care process (workflow) engine invokes activities
  in accordance with the process rule base.

13
Where are guideline tasks handled?

• Process engine sequences activities
• Process knowledge may
• make decisions
• interpret data
• refine actions
• or these tasks may be embedded in components
  invoked by the engine.

14
UML for Process Representation

• UML universal software development modelling
  language
• Consists of 9 different notations for different
  aspects of software development cycle e.g.
  business modelling, requirements modelling etc.
• Activity Graphs currently being enhanced for
  workflow representation
• UML v1.4, and in 2002/3 UML v2.0

15
Sample UML Process
Medical Record No.
Activity/Task
TestResult
Clinical Test
Data
TestResultY
TestResultX
Data flow
Start Treatment
Refer back to GP
Control flow
Activity 4
16
Minimal Data Flow in Medilink
Control Data Data that comes into existance only
because of the workflow managment Only relevant
internally for a WfMS Examples local variables
of workflow, or data (e.g. pointer to a file)
passed between subworkflows Control data is
discarded when workflow is finished
Production Data Exists without WMS is external
to WfMS Is used by WfMS Examples Data that can
be accessed through Synapses

• In MediLink
• Production data is generally not passed between
  activities
• Production data can temporarily become control
  data (e.g. MRN, Results of Tests for
  conditioning)
• Production data flow is between MediLink Workflow
  components (e.g. FPG Test) and the respective
  databases (in case of storage) or Synapses (in
  case of querying)

17
Case Study Diabetes Diagnosis and Management

• Model care process in St James Hospital Diabetic
  Day Care Centre.
• Produced 3 guidelines
• Coordination Guideline
• Diabetes Diagnosis Guideline
• Diabetes Management Guideline

18
Coordination Guideline
19
Diagnosis Guideline
FPGValuelt6.1fpgCondition1
FPGValuegt7fpgCondition3
6.1ltFPGValuelt7fpgCondition3
FPGValuelt7conclusiveCondition1
FPGValuegt6.17.8ltPPValuelt11.1oggtCondition1
FPGValuegt7conclusiveCondition2
FPGValuegt7PPValuegt11.1oggtCondition5
FPGValuelt6.17.8ltPPValuegt11.1oggtCondition4
FPGValuelt6.1PPlt7.8oggtCondition2
6.1ltFPGValuelt7PPValuegt7.8oggtCondition3
20
Management Guideline
21
Issues for UML Process Models

• Can all significant aspects of a (procedural)
  guideline be captured?
• Are UML guidelines readable and customisable by
  clinicians?
• Are UML-based guidelines automatable?
• Next

22
From Guideline system process Representation to
Guideline execution/automation
Rule set Specification (JESS)
Guideline
XMI Representation of Guideline
23
Process Definition (XML)
Process Mappings (XSLT)
Activity Definition (XML)
XML2EJB
Pre-existing Building Blocks
CareflowEngine
Pseudo Component 1
Process Manager
Wrapper
Message Queue
Pseudo Component 2
Process Interpreter (Rule Engine)
State Change Events
Wrapper
J2EE Platform
24
Technical Architecture

• Technologies employed
• UML (Graphical Guideline representation)
• XMI (Textual Guideline representation)
• XSLT (Guideline filtering and sieving)
• XML (Process and Activity rep. (prior to
  runtime))
• EJB (Process and Activity rep. (during runtime))
• JESS (Rules engine, Java Expert System Shell)
• Tomcat, servlets JSP (Component
  Communication)

25
Components in Distributed Clinical environment

• Guideline Invocation Component
• Serene (Process Mgr)
• Synapses
• TOPS
• Appointment Scheduler
• Report/ Letter Writer
• Lab test ordering/results (FPG Test, OGTT (2hr),
  random urine, various other blood tests,

26

Component Description Template
                                           
Component Name Name of component Input
Parameters Data required for one execution of the
component Output Parameters Resulting data
returned from one execution of the
component Interface Specification Specification
of interface of the component in whatever
language is native for that component e.g. in IDL
for Corba Component etc. Description Brief
description detailing the role of the component
within the overall system. Technology
Platform e.g. Enterprise Java Bean running on
JBOS, Java Implementation etc. Medilink
Personnel Name of Medilink personnel
responsible for Responsible for design,
Implementation integration of this Component
component e.g. Mark Gargan

27

3rd Party CASE Tool (Guideline) Modeller
Guideline Compilation Unit
28
Current Status of Trial

• Guidelines modelled in UML (reviewed by Diabetes
  Centre, St James Hosp.)
• Generation parsing of XMI based Guideline
  description
• Integration of individual clinical servers (e.g.
  EHCR Server)
• Integration with heterogeneous protocol system
  (ongoing)
• See demo later.

29
Finally on Guidelines

• Good case for UML based process oriented
  Guideline representation
• Benefits from leveraging mainstream technology -
  larger choice of modelling tools, easier
  integration, reduced cost etc.
• However, UML still evolving .
• Computable UML is not here yet but there have
  been significant advances

30
Protocol Knowledge

• TOPS A Computer-Based System for the Management
  of Clinical Protocols
• TOPS encodes protocol knowledge as ECA rules.

31
TOPS ECA Rule-Based Specification of the
Micro-Albuminuria Protocol
ECA Rule 2nd_positive_confirmed_microalbuminuria
UML Statechart for the micro-albuminuria protocol
Event 2_of_3_elevations
Condition true
Action Microalbuminuria confirmation
ECA rules are derived from state and
transition attributes
State gt state of patient in the context of
protocol
32
TOPS Example ECA Rules
Rule ma_screening_first_positive, ON
newResult(ACR), WHEN result(ACR) gt 3 AND
result(ACR) lt 30, DO change_patient_state_to(
first_positive)
Rule first_positive_test_order, ON
orderDate(), DO orderTest(ACR, patient_id)
33
TOPS Management Planes
SPECIFICATION Plane
Clinical Protocol
Protocol Linked to individual patient
Operations and Queries
MANIPULATION Plane
Patient Plan
Static Dynamic Manipulation Querying
Patient Plan Rules customised to monitor patient
record
ECA Rules
EXECUTION Plane
Each ECA rule maps to one or more database
triggers
Database Triggers
34
TOPS Approach
EHCR

35
TOPS Execution Flow
Specification
Phase
Category
protocol specification
Customisation
Patient Clinical
Management
Phase
Data
(querying
Patient test
modification)
ordering plan
From other MediLink Components e.g. Synapses
EHCR Server and Serene Workflow Engine
Installation
Phase
Instantiated patient
test plan
Execution
Test Results, Queries
Phase
To other MediLink componets
36
TOPS MediLink Integration
37
TOPS Summary

• Full-scale manageability of protocol
  specifications and patient-specific instances
• Potential for a more efficient and effective
  healthcare delivery
• Early detection with continuous surveillance
  system
• Timely and appropriate intervention according to
  agreed local protocols
• Ensure relevant tests ordered and avoid
  unnecessary requests and
• Synergistic interaction with other Medilink
  components.

38
Knowledge Implicit in Cases

• A collection of patient cases with expert
  solutions (diagnosis, treatment, )
  encapsulates expert knowledge.
• Case-based reasoning is a lazy way of
  exploiting this knowledge.
• Particularly useful for weak-theory domains
• CBR can support knowledge discovery.

39
Case-based Reasoning

• Match the current problem with ones already
  encountered.
• Apply solutions of matching past problems to
  current problem.
• Collection of patient data with diagnosis is the
  case-base
• Knowledge resides in collection of problem cases
  and their solutions.
• Competence improves as cases are added

40
The CBR Idea
Adapt

• SP Problem Spec.
• SL Problem Soln.
• Objective is to avoid modelling first principles
  reasoning (FP)
• Retrieve SP - similar problem to SP and adapt
  solution

SL
SL'
FP
SP
SP'
Retrieve
41
Case Retrieval

• What is the difference between retrieval in CBR
  and data-base retrieval?
• Match need not be exact
• Based on Similarity
• e.g. k-Nearest Neighbour, or Decision Trees
• Can be 2-stage process
• MAC-FAC many are called, few are chosen

42
CBR in the Context of Medilink
43
Case-base Creation
?
?
?
?
?
?
?
?
?
?
Data Base
Design Tool
2
1
Case Base
Designer
CBR Tool
User
44
Case-Base Maintenance

• Gold-Standard Cases
• Small selection of hand-selected cases
• Identified by committee of experts
• Depends on Pareto principle (80 20 rule)
• Use naturally occuring cases
• Issues
• Minority Class False Pos. vs False Neg.
• Relative cost of errors
• Redundancy

45
CBR Use of Outcomes
Case Structure B
Case Structure A
Case description
Solution
Outcome

• Case structure A models competence of expert who
  proposed original solutions
• Case structure B brings evidence of previous
  cases to bear potentially improves decisions.

46
Review Knowledge in Medilink

• Medilink captures knowledge
• Process knowledge as care guidelines
• Protocols as ECA rules in an active database
• Expert solutions via CBR
• and
• Evidentiary knowledge via
• model building, simulation training
• CBR, process refinement - for the future!