1 / 53

Large Scale Distributed Information Systems Lab at University of Georgia http://lsdis.cs.uga.edu

Workflow Process Management and . Enterprise Application Integration in Healthcare. Requirements, Applications, Technology and Research. Amit Sheth Keynote Address HEALTHCOM99 Sydney, AU Jan.11, 1999. Large Scale Distributed Information Systems Lab at University of Georgia

raanan
Download Presentation

Large Scale Distributed Information Systems Lab at University of Georgia http://lsdis.cs.uga.edu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Workflow Process Management and Enterprise Application Integration in Healthcare Requirements, Applications, Technology and Research Amit Sheth Keynote Address HEALTHCOM99 Sydney, AU Jan.11, 1999 Large Scale Distributed Information Systems Lab at University of Georgia http://lsdis.cs.uga.edu Thanks: > Krys Kochut, John Miller and METEOR Team> NIST-ATP, IONA Technologies, Informix, ...

  2. Introduction Comprehensive Healthcare IT solutions require • broad variety of process management applications, and • enterprise application integration in a rapidly changing, distributed, and heterogeneous computing environments.

  3. Application NeoNatal Clinical PathWays Genome Sequencing Eligibility-Referral Immunization Tracking Key Characteristics Clinical, single site/server Non-medical, multiple user organizations, two servers Administrative, two participating organizations Clinical and Administrative, multiple servers, multiple organizations Reprsentative Healthcare Applicationsfor which the METEOR EAppS has been used

  4. Neonatal Clinical Pathways Nurse Coordinator Neonatologist Nurse Server

  5. Neonatal Clinical Pathways • Multiple inter-related clinical pathways or treatment plans for premature, underweight babies (head ultrasound, metabolic screen, nutrition, immunizations, etc.) • Alert on test to be ordered, enter tests and review results, update database, print reports • Users: nurse coordinator, nurse, neonatologist • single server, Web-based clients

  6. Head Ultrasound Workflow

  7. Multi-institutional Genome Sequencing Users in different labs worldwide Georgia Solaris Server SGI Server Legacy App Legacy App

  8. Data Analysis in a Multi-institution Genome Sequencing Enterprise Task 1 Task 2 Task i Raw output from DNA sequencing machines from multiple institutions Fully sequenced and annotated genome ... Automatic and human-computer data analysis tasks running on heterogeneous servers

  9. Characteristics of Data Analysis Tasks • Many existing legacy data analysis applications and new applications running • different servers (SGI and Solaris) • Each human-computer task performed by an expert who specializes in that task; experts are located at different institutions throughout the world

  10. Insurance company Sending organization Receiving organization Eligibility and Referral

  11. Eligibility and Referral(i.e., “patient dumping”) • Sending Organization -- Receiving Organization -- (optionally insurance company and ambulance services) • Two independent workflows with interoperability, optionally EDI with other organizations

  12. Sending Organization Receiving Organization

  13. An Example of Mission-criticalEnterprise Application Developed using METEOR EAppS

  14. CLINICAL SUBSYSTEM • Generates: • Alerts to identify patient’s needs. • Contraindications to caution providers. Reminders toparents Health providers can obtain up-to-date clinical and eligibility information CT Hospitals and clinics update central databases after encounters Reports to state Health agencies can use reports generated to track population’s needs SDOH and CHREF maintain databases, support EDI transactions Hospitals and case workers can reach out to the population State and HMO’s can update patient’s eligibility data HMOs can keep track of performance TRACKING SUBSYSTEM Schematic of Immunization Tracking

  15. Implementation Testbed: Immunization Tracking Demoask us for a demo Admit Clerk Triage Nurse Doctor/ NP Maternity Ward Administrator Case Worker (Solaris) DBMS (Windows NT) CORBA Hospital Info System MPI MEI Web Server Web Server (Solaris) Immunization Database DBMS (Solaris) Encounter Database CHREF Hospital EDI CHREF/SDOH Clinic Office Practice Mgmt System (Solaris) DBMS Admit Clerk Triage Nurse Doctor/ NP Web Server Encounter Files/Databases Insurance Eligibility Database

  16. N N N Enter Patient Info. Enter Patient Info. Enter Patient Info. Web-based Implementation Admit Clerk Task Triage Nurse Task Update Personal Data Update Local Database Start . . . . Start Stop Collect Vitals Enter Patient Info. Generate Alerts Check Eligibility Workflow Design Updated Results Implementation Generate Triage Nurse’s Page Update Personal Data N Generate Alerts CGI CGI Display Worklist Enter Patient Update Local Database CGI CGI CGI CGI PULL N Add to Worklist DBMS HTTP WORKLIST HANDLER N N CGI Machine Boundary Alert Results Eligibility Results Check Eligibility Worklist File N Web Page Submit Button

  17. Web-based Implementation N N N N WORKLIST HANDLER WORKLIST HANDLER WORKLIST HANDLER Enter Patient Info. Worklist File Worklist File Worklist File Admit Clerk Task Triage Nurse Task Update Personal Data Update Local Database Start . . . . Start Stop Collect Vitals Enter Patient Info. Generate Alerts Check Eligibility Workflow Design Updated Results Implementation Generate Triage Nurse’s Page Update Personal Data N Generate Alerts CGI CGI Display Worklist Enter Patient Update Local Database CGI CGI CGI CGI PULL Add to Worklist DBMS HTTP N N CGI Machine Boundary Alert Results Eligibility Results Check Eligibility N Web Page Submit Button

  18. Provider Interface:Immunization Reco’s List of overdue vaccinations Link to contraindication info obtained from the Internet Clinical update to “administer vaccination”

  19. Admit Clerk Task Triage Nurse Task Update Personal Data Update Local Database Start . . . . Start Stop Collect Vitals Enter Patient Info. Generate Alerts Check Eligibility Check Eligibility Workflow Design Implementation Updated Results Update Personal Data Patient Data (CORBA) N Update Local Database Generate Alerts CORBA CORBA Add to Worklist Enter Patient CORBA CORBA CORBA HTTP Worklist Handler N DBMS N N CORBA Enter Patient Info. Machine Boundary Alert Results Eligibility Results Check Eligibility Control Flow Web Page N Submit Button CORBA-based Implementation

  20. Requirements of mission-critical healthcare applications that METEOR supports Some of the important requirements for this application include: • Support for a distributed architecture in a heterogeneous computing environment. At the level of any user of the system, this distribution should be transparent • Support for inter- and intra-enterprise wide coordination of tasks • Provision of a standard user-friendly interface to all users of the system • Support for a variety of tasks: transactional and non-transactional, user and application

  21. Requirements of mission-critical healthcare applications that METEOR supports • Capability of using existing DBMS infrastructure and databases across organizations • Low cost of system for the providers and user organizations • Ease of modification (re-design), scalability, extensibility and fast design-to-implementation • Open architecture, use of standards (e.g., CORBA, CORBAmed, OMG WF, WfMC, SWAP) and middleware (JDBC) • Security authorization for users and secure communication (required as patient data is typically confidential)

  22. special test Workflow Component Repos. Adaptive Workflow Example 1 If initial exam identifies needs for additional procedure in the blood test, the task/subprocess component is obtained from the repository and added to the subprocess standard test get blood write report This example is from Han et al.

  23. Adaptive Workflow Example 2 • Comorbidity: new lab result identifies previously unknown illness or health condition that requires additional health management in addition to the current condition. • New related workflow (or subworkflow) is kicked off.

  24. State of the art technology, products and research

  25. Market Approaches to Workflow Internet ORB e-mail workgroup/ collaborative document mgmt. imaging database TP-monitoring

  26. Key conclusion from DocuLab’s workflow product comparison study • Products that allow development of complex applications, provide flexibility and support integration are very hard to use, take too long and require experience programmers (and are still not quite comprehensive) • Easy to use products are too restrictive --and are useful for small or standard applications only METEOR’s objective is to avoid significant compromise.

  27. What is lacking from state of the art in Workflow Technology • Primarily centralized, client/server architectures • Difficulty in integrating with existing applications and databases, not meant for heterogeneous, multi-server environments • Static workflows that can be fully defined before enactment starts • Focus on repetitive processes Most products are, however, suitable for many office automation and other human oriented processes.

  28. Research Disciplines Contributing to to Workflow Management Database Management/ Information Systems Distributed Computing/Systems Software Engineering, HCI, etc. MIS/ Reengineering/ Methodology Software Process CSCW Quantitative and Formal Methods/Modeling Organizational Science

  29. Enterprise Application Integration [EAI] • The average Fortune 2000 company relies on 49 enterprise-level applications to run its business and spends 25 to 33 percent of its IT budget just to get tem to talk to each other [Dan Sholler, Meta Group] • Systems integration costs in many cases amount of 40 percent of IT costs

  30. App App Packaged App Legacy App User Task Message/Data Tools/Architecture of current EAI products/solutions Business Object/Process Tool/Architecture of the METEOR Enterprise Application Development & Integration METEOR Component METEOR Component User Task HOST 1 HOST 4 Adapter Adapter Broker METEOR Component METEOR Component METEOR Component Adapter Adapter Application EDI Database Transaction HOST 2 HOST 3 Services and Business Objects Publish/Subscribe; event-based messaging Distributed Object Management (ORB) Enterprise Java Beans DCOM Messaging/PersistentQueue Middleware

  31. Builder REPOSITORY MONITOR AUTOMATIC CODE GENERATION TASK Mgr. TASK Mgr. TASK Mgr. AND TASK TASK TASK DB Application TASK Mgr. WEB / CORBA TASK METEOR Architecture

  32. METEOR2 EAppS[Enterprise Application Suite of Tools and Services] End Users

  33. METEOR Model • Integral support for human and application tasks • transactional and non-transactional tasks • human tasks: forms, collaborative tasks • automated tasks: database access, legacy applications • Complex control and data dependencies • much more

  34. METEOR Workflow Builder Service • Comprehensive set of graphical tools for building workflow process applications • Map Designer • Data Designer • Task Designer • Web Form Designer • Exception Designer

  35. WebWork Application Development .wil .spec Workflow Designer Workflow Generator Application Prototype source Workflow Application Task Customizer Page Customizer Specification Customizer .cc .html .spec

  36. Web Enabled and Web Based Engines Web Based Web Enabled Centralized Distributed Front End Enactment, monitoring, administration Vendor1 Vendor2 Vendor3 OzWeb Endeavors WebWork Error handling Recovery (Transactional Support) Distributed Scheduling EJB CGI Tcl, Java, XML

  37. LPS OVERVIEW Host B Host A Workflow Monitor GRM Cleanup Task Workflow Administrator GPS Host C Object Request Broker (CORBA) Host E LRM LRM Web TTM Database Task LPS DBMS LRM LPS Web Server Activate Message Data Object GPS Global Persistence Store GRM Global Recovery Manager LPS Local Persistence Store LRM Local Recovery Manager NtTM Non-transactional Task Manager TM Task Manager TTM Transactional Task Manger UTM User Task Manager NtTM UTM Application Task User Task Watchdog Host D

  38. ORBWork Enactment Service Designed to address a variety of shortcomings found in today’s component middleware, enterprise integration, and workflow process management systems, it supports the following capabilities: • Integration of application components and databases on disparate distributed and heterogeneous computing environments across enterprise intranet and extranet boundaries • A fully distributed and highly scalable enterprise application process enactment system capable of supporting dynamic business processes

  39. ORBWork(continued) • Utilization of open and industry standards such as CORBA/IIOP, Java, JDBC, HTTP, and OMG Workflow Facility for developing open, distributed, object-based, interoperable enterprise applications • Support for cross-platform portability of tasks in business processes (by exclusively developing them in Java) • Provision for a browser-based Web user interface for the end-users and the administrators.

  40. ORBWork’s fully distributed scheduling and flexible placement

  41. Achieving Scalability • Use of a fully distributed scheduler. • Component task schedulers “mirror” the workflow map design. • Natural distribution of scheduling and task activation functions among participating hosts. • Task schedulers can be replicated to increase the load handling potential. • Task managers can be distributed among many hosts to balance the load.

  42. Dynamic Changes Dynamic changes both to the enterprise application or workflow process schema and to the individual workflow process instances. Administrator can easily modify the schema at runtime by acquiring the new information from the repository, or even by modifying the specification by HTTP-based direct interaction with the scheduler.

  43. ORBWork implementation:Utilizing ORBIX’s features

More Related