A Model-Integrated,Guideline-Driven,Clinical Decision-Support System

Janos L. Mathe, Andras Nadas, Janos Sztipanovits

November 11, 2010

INSTITUTE FOR SOFTWARE INTEGRATED SYSTEMS

ealth Infrastructures

Outline

• STEEP: Project Overview• Integration Challenge

– Systems architecture– Approach

• Reusability Challenge– Knowledge architecture– Approach

• Summary

Sepsis Treatment Enhanced through Electronic Protocolization (STEEP)

– TRUST testbed for a new generation of privacy-aware health information systems

– A fully model-integrated clinical decision support and patient management system

– Developed jointly by TRUST and VUMC research teams

– Funded by NSF-TRUST, NIH and VUMC– Currently under clinical trial in the Medical ICU

(MICU) and Surgical ICU (SICU) of VUMC

Project Overview Integration Challenge Reusability Challenge Summary

Goals of STEEP•

Support for managing

septic patients using form

ally modeled

evidence-based guidelines–

Improve adherence to

evidence-based guidelines in disease m

anagement

•Establish a real-life experim

ental platform

for privacy-aware H

IS –

Model-integrated

approach for synergizing utility under privacy constraints

Project Overview Integration Challenge Reusability Challenge Summary

1. Identify patients based on modified SIRS criteria and prompt clinical teams2. Provide treatment recommendations real-time based on live patient data

4. Integrate with HIS services of the hospital

SurveillanceTool

Patient Management

Dashboard

Computerized Provider

Order Entry(CPOE)

Execution Engine

GUI

STEEP

Physician Patient

EMR DB Service

Concept of Operation for STEEP

3. Monitor and track treatment trajectory and manage information flows

Project Overview Integration Challenge Reusability Challenge Summary

Meaning of “Model Integrated”

Execution Engine

GUI

STEEP

Protocol ModelsGME

Physician

Model-based Runtime

ConfigurationXML

T

Configure, Integrate and Execute system using the Protocol Models

• Formally defined (structural and behavioral semantics

• Analyzable and translatable

Build Protocol Models

Project Overview Integration Challenge Reusability Challenge Summary

Execution Engine

GUI

STEEP

Protocol ModelsGME

Physician

Model-based Runtime

ConfigurationXML

T

Configure, Integrate and Execute system using the Protocol Models

• Formally defined (structural and behavioral semantics

• Analyzable and translatable

Build Protocol Models

Meaning of “Model Integrated”Project Overview Integration Challenge Reusability Challenge Summary

Meaning of “Model Integrated”

Execution Engine

GUI

STEEP

Protocol ModelsGME

Physician

Derived Protocol Representation

XML

T

Configure, Integrate and Execute system using the Protocol Models

• Formally defined (structural and behavioral semantics

• Analyzable and translatable

Build Protocol Models

Project Overview Integration Challenge Reusability Challenge Summary

Architecture of the Software Suite

Server

Client

HL7Patient

Data

Orders to HEO

Model-based Runtime

Configuration

File

IO

ProtocolVisualization

Protocol and Orders Mediator

GUI

TreatmentStatus

PatientStatus

AJAX

ChartVisualization

Chart DataFormatter

HTTP

EMR Interface

CPOEInterface

Decision Support(individualized protocol execution)

Protocol Execution Engine

JNDI / EJB3

JNDI / EJB3

Persistency DB

JDBCHibernate

JDBCHibernate

Execution Engine

GUI

STEEP

JND

I / EJB3

JNDI /

EJB3

• Code is fully reusable• Model is changing and complex• Environment is very heterogeneous

Project Overview Integration Challenge Reusability Challenge Summary

Clinical Trial• Started in October, 2010

• 6 months late and ongoing

• Performed by Attendants and Fellows in the MICU and SICU

• Long period of hands-on tests, GUI debugging, quality reviews and evaluations

• Integration is a significant challenge (seemingly mundane, but this is the source of most systems challenges and tightly linked to privacy/security requirements

• Reusability is a crucial – solution requires compositionality on the level of models

Lessons learnt (so far)

Project Overview Integration Challenge Reusability Challenge Summary

Outline

• STEEP: Project Overview• Integration Challenge

– Systems architecture– Approach

• Reusability Challenge– Knowledge architecture– Approach

• Ongoing work

Conditions for Clinical Integration

The process required:1. passing of the institutional HIPAA (privacy),

security and quality review process2. the integration of STEEP into Vanderbilt's

clinical information systems, including– the EMR, Order Management (CPOE), Medical

Administration and Surveillance & Alert Management systems

Project Overview Integration Challenge Reusability Challenge Summary

Integration Architecture

CPOE(Order Management)

UI

DB

User-specific Settings

Role-specific Settings

Lab SystemPatient Management SystemNursing SystemMedication Tracking SystemCPOEPatient Website

Patient Management System

Dashboard

STEEP GUI

DB

EMR DB Service(Data Integration)

Centralized Data Cache

Historic Data Warehouse

Surveillance Tool(Sepsis Alert)

Rule Execution

DB

STEEP(Sepsis Management)

STEEP GUI

Execution

DB

Project Overview Integration Challenge Reusability Challenge Summary

Security/Privacy Related Questions

• STEEP is integrated into a live clinical environment:– Interact with personnel (providers) with different

roles– Exchanges information with external systems

• How to control access to data and functionality?• What are the consequences of access violations?

– Privacy– Safety

Project Overview Integration Challenge Reusability Challenge Summary

Integration Architecture

CPOE(Order Management)

UI

DB

User-specific Settings

Role-specific Settings

Lab SystemPatient Management SystemNursing SystemMedication Tracking SystemCPOEPatient Website

Patient Management System

Dashboard

STEEP GUI

DB

EMR DB Service(Data Integration)

Centralized Data Cache

Historic Data Warehouse

Surveillance Tool(Sepsis Alert)

Rule Execution

DB

STEEP(Sepsis Management)

STEEP GUI

Execution

DB

Closed Environment

• Authentication• Does information leave

the closed environment (on a new path)?

• Clinical trial evaluation: Conforms with HIPAA?

– Non-discrimination– Opt-out option– Tracking of patient

information used for the purpose of research

Project Overview Integration Challenge Reusability Challenge Summary

Initial AnalysisPolicy Name Description Specific example Required information

User authentication • Users get authenticated based on their credentials

• Number of failed attempts gets logged (dynamic policy)

• Users invoking SCPM are checked to be logged in on the same Star server where the request is coming from

User ID, Password

Access location-based restriction • Users working from an unsafe location should not be provided with full functionality

• Physicians working from home are provided with read only access to SCPM treatment interface

IP location

Role-based functionality restriction

• For certain types of users the provided set of functionality is limited

• Interns without specifying their attending are provided with read only access to SCPM treatment interface

User ID, Acting role

Role-based work delegation • Certain types of users can delegate work to others, thus elevating their rights on a case-by-case basis

• Interns have to provide information on who’s behalf are they acting upon (e.g.: “MyBoss”) when accessing certain functionalities (e.g.: view patient, order medication for patient)

• The provided “MyBoss” information needs to be checked: Role(Usr)=“Intern” Superior(Usr)=“MyBoss” & Role(MyBoss)=“Attending”

• Learnt and verified superior is stored for a period of time (e.g.: session/day/semester) and used in subsequent steps

User ID, Acting role, Superior

Role-based treatment history variation

• Different roles should have different views of the same information

• Order history contains dosing information and is chronologically sorted for physicians, but contains no dosing info and sorted alphabetically for billing personnel

User ID, Acting role

Role-based filtering for testing • Users can have alternate reasons when accessing functionality. Theses reasons cannot always be automatically detected. Based on user selection of roles/purpose/etc. alternate behavior should be expected

• For the purpose of demoing/testing a functionality in a live environment, only de-identified patient information should be visible (physician demoing, IT personnel testing)

User ID, Acting role

Role location-based filtering • Location associated with the role(s) of a user is used to filter the pool of patients

• SICU patients are filtered for an SICU physician, ED patients for the ED physician repsectively

User ID, Acting role, Role-based location

Project Overview Integration Challenge Reusability Challenge Summary

Outline

• STEEP: Project Overview• Integration Challenge

– Systems architecture– Approach

• Reusability Challenge– Knowledge architecture– Approach

• Ongoing work

Lessons Learnt• Development of the Clinical Process Modeling Language (CPML)

has been a significant effort

– CPML integrates many different kinds of knowledge (medical guidelines, execution semantics, privacy policies, interface abstractions of connected systems, etc.)

• Our conclusion is that for future problem domains we need to decompose the knowledge CPML into sub-languages that capture separate knowledge components and obtain Protocol Models via model composition

– Reusable model libraries built for these separate aspects will then be used to generate the integrated domain specific models

Project Overview Integration Challenge Reusability Challenge Summary

Status of the Modeling Language• Medical guideline modeling using

ontology language- general medical ontology, condition

specific ontology, HCO specific ontology

• Execution platform modeling- processes, triggering events, actions

temporal relations

• Interface modeling- messages, information content, agents

• Policy modeling- roles, messages, information content,

constraints

Project Overview Integration Challenge Reusability Challenge Summary

Composition of Modelsusing Model-based Techniques

+ +

UI Configuration

+ +

Patient-basedCIG Specialization

+ +

HCO-specificData Concepts

+ +

HCO-specificAction Concepts

HCO-specific Security& Privacy Policies

+ +

ProtocolModels

TExecution PlatformModels

Medical OntologyModels

HCO-specific, Integrated, ExecutableProtocol Models

Sepsis Medical OntologyModeling of STEEP

Execution Semantics

Project Overview Integration Challenge Reusability Challenge Summary

Summary

• Model-integrated TRUST testbed– Clinical process modeling with privacy rules

• Being introduced in ICUs at VUMC

• Lessons Learnt– Separation on concerns is important

• Use of models can help• Supports reuse• Provides analyzability

Project Overview Integration Challenge Reusability Challenge Summary