a model-integrated, guideline-driven, clinical decision-support system janos l. mathe, andras nadas,...
TRANSCRIPT
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