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 OverviewIntegration ChallengeReusability ChallengeSummary

Goals of STEEP Support for managing septic patients using formally modeled evidence-based guidelines – Improve adherence to evidence-based guidelines in disease management Establish a real-life experimental platform for privacy-aware HIS – Model-integrated approach for synergizing utility under privacy constraints Project OverviewIntegration ChallengeReusability ChallengeSummary

1.Identify patients based on modified SIRS criteria and prompt clinical teams 2.Provide treatment recommendations real-time based on live patient data 4.Integrate with HIS services of the hospital Surveillance Tool 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 OverviewIntegration ChallengeReusability ChallengeSummary

Meaning of “Model Integrated” Execution Engine GUI STEEP Protocol Models GME Physician Model-based Runtime Configuration XML T T Configure, Integrate and Execute system using the Protocol Models Formally defined (structural and behavioral semantics Analyzable and translatable Build Protocol Models Project OverviewIntegration ChallengeReusability ChallengeSummary

Execution Engine GUI STEEP Protocol Models GME Physician Model-based Runtime Configuration XML T 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 OverviewIntegration ChallengeReusability ChallengeSummary

Meaning of “Model Integrated” Execution Engine GUI STEEP Protocol Models GME Physician Derived Protocol Representation XML T T Configure, Integrate and Execute system using the Protocol Models Formally defined (structural and behavioral semantics Analyzable and translatable Build Protocol Models Project OverviewIntegration ChallengeReusability ChallengeSummary

Architecture of the Software Suite Server Client HL7 Patient Data HL7 Patient Data Orders to HEO Orders to HEO Model-based Runtime Configuration Model-based Runtime Configuration File IO Protocol Visualization Protocol Visualization Protocol and Orders Mediator GUI Treatment Status Patient Status AJAX Chart Visualization Chart Visualization Chart Data Formatter Chart Data Formatter HTTP EMR Interface CPOE Interface CPOE Interface Decision Support (individualized protocol execution) Decision Support (individualized protocol execution) Protocol Execution Engine JNDI / EJB3 Persistency DB JDBC Hibernate JDBC Hibernate JDBC Hibernate JDBC Hibernate Execution Engine GUI STEEP JNDI / EJB3 Code is fully reusable Model is changing and complex Environment is very heterogeneous Code is fully reusable Model is changing and complex Environment is very heterogeneous Project OverviewIntegration ChallengeReusability ChallengeSummary

Clinical Trial Started in October, 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 OverviewIntegration ChallengeReusability ChallengeSummary

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 process 2.the integration of STEEP into Vanderbilt's clinical information systems, including – the EMR, Order Management (CPOE), Medical Administration and Surveillance & Alert Management systems Project OverviewIntegration ChallengeReusability ChallengeSummary

Integration Architecture CPOE (Order Management) CPOE (Order Management) UI DB User- specific Settings Role- specific Settings Lab System Patient Management System Nursing System Medication Tracking System CPOE Patient Website Lab System Patient Management System Nursing System Medication Tracking System CPOE Patient Website Patient Management System Dashboard STEEP GUI DB EMR DB Service (Data Integration) EMR DB Service (Data Integration) Centralized Data Cache Historic Data Warehouse Surveillance Tool (Sepsis Alert) Surveillance Tool (Sepsis Alert) Rule Execution DB STEEP (Sepsis Management) STEEP (Sepsis Management) STEEP GUI Execution DB Project OverviewIntegration ChallengeReusability ChallengeSummary

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 OverviewIntegration ChallengeReusability ChallengeSummary

Integration Architecture CPOE (Order Management) CPOE (Order Management) UI DB User- specific Settings Role- specific Settings Lab System Patient Management System Nursing System Medication Tracking System CPOE Patient Website Lab System Patient Management System Nursing System Medication Tracking System CPOE Patient Website Patient Management System Dashboard STEEP GUI DB EMR DB Service (Data Integration) EMR DB Service (Data Integration) Centralized Data Cache Historic Data Warehouse Surveillance Tool (Sepsis Alert) Surveillance Tool (Sepsis Alert) Rule Execution DB STEEP (Sepsis Management) 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 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 OverviewIntegration ChallengeReusability ChallengeSummary

Initial Analysis Policy NameDescriptionSpecific exampleRequired 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 OverviewIntegration ChallengeReusability ChallengeSummary

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 OverviewIntegration ChallengeReusability ChallengeSummary

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 OverviewIntegration ChallengeReusability ChallengeSummary

Composition of Models using Model-based Techniques ++ + UI Configuration ++ + Patient-based CIG Specialization Patient-based CIG Specialization ++ + HCO-specific Data Concepts HCO-specific Data Concepts ++ + HCO-specific Action Concepts HCO-specific Action Concepts HCO-specific Security & Privacy Policies HCO-specific Security & Privacy Policies ++ + Protocol Models Protocol Models T T Execution Platform Models Execution Platform Models Medical Ontology Models Medical Ontology Models HCO-specific, Integrated, Executable Protocol Models HCO-specific, Integrated, Executable Protocol Models Sepsis Medical Ontology Modeling of STEEP Execution Semantics Project OverviewIntegration ChallengeReusability ChallengeSummary

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 OverviewIntegration ChallengeReusability ChallengeSummary