Healthcare Enterprise Process Development and Integration Kemafor Anyanwu, Amit Sheth, John Miller, Krys Kochut, Ketan Bhukhanwala



Download 0.67 Mb.
Date01.02.2017
Size0.67 Mb.

Healthcare Enterprise Process Development and Integration


Kemafor Anyanwu, Amit Sheth, John Miller, Krys Kochut, Ketan Bhukhanwala



Abstract


Healthcare enterprises consist of many groups and organizations. Many of their activities involve complex work processes that span groups, organizations, and enterprises. These processes involve humans and automated activities that are carried out over or supported by heterogeneous hardware and platforms, and involve a variety of software applications and information systems. Management of these processes, and their automation is increasingly playing an important role for improving the efficiency of the healthcare enterprise..
In this paper we look at four very different healthcare and medical applications that involve investigative, clinical and administrative functions. Using these applications, we investigate requirements for developing enterprise applications that involve a coordination of a variety of tasks performed by humans, information systems and databases, and new and legacy applications. This study leads to the need for two software technologies: enterprise application integration and workflow management.
We also present the METEOR System that leverages the Java, CORBA and Web technologies to provide the ability to develop enterprise applications requiring integration and workflow management. Our success in prototyping these applications, is also due in part to extensive collaboration with our healthcare industry partners.

1. Introduction


The recent push for healthcare reform has caused healthcare organizations to focus on ways to streamline their processes and deliver high quality care at low cost. This has precipitated the reviewing and upgrading of clinical and administrative protocols and the increased use of computer systems to improve efficiency of these processes. As a result, a wide variety of computer software systems are currently being used in healthcare organizations such as Application Systems, Document Systems and Workflow Management Systems. This paper discusses the use of the METEOR System for managing a broad variety of healthcare processes.
Healthcare processes are very complex, involving both clinical and administrative tasks, large volumes of data and a large number of people, patients and personnel. The care process for one patient will have different types of processes may interact at points that are not always predetermined. An out-patient clinic visit may involve administrative tasks performed by an administrative assistant (like obtaining updated patient information, e.g. address; checking patient eligibility), clinical tasks performed by a doctor or nurse (like obtaining blood pressure, temperature, administering a clinical procedure e.g. injection, examination. These processes also include financial related tasks like, patient billing, which will typically be performed by a different group like the accounting department. For an in-patient hospital visit, this scenario may involve many more tasks and a long-running process that lasts at least as long as the duration of patient hospitalization. These processes are also very dynamic. For example, a care pathway for a patient with disease condition ‘A’ may evolve to a more complex work process if another disease condition ‘B’ is discovered in the course of treatment of ‘A’, because both problems may have different care pathways but may still have to be treated concurrently.
Many workflow products adequately support relatively simple processes involving document and forms processing, imaging, ad-hoc processes with synchronous and asynchronous processes, etc. [Fischer 95, Silver 95]. However, they fall short in meeting the requirements of complex, large-scale, and mission-critical organizational processes [Sheth 96, Sheth and Joosten 96] such as healthcare processes. Such processes span multiple organizations (e.g., child immunization tracking discussed in this paper, also see [Sheth et.al. 96]), run over long periods of time [Dayal et.al. 91] (e.g., clinical trial process), require more support for dynamic situations (e.g., clinical pathway process), or require a highly scalable system to support large instances of workflows (e.g., supporting automated process in a genetics lab [Bonner et.al. 96]). Many of the workflow applications that support real-world processes also need to be integrated with (or reuse) existing (legacy) information systems, need to run over distributed, autonomous and heterogeneous computing environments [Georgakopoulos et.al.. 95], require support for transactional features (especially recovery) and error handling [Worah et.al. 97], and need varying degree of security (including authorization, role based access privileges, data privacy, and communication security). Emerging and maturing infrastructure technologies for communication and distributed object management (e.g., CORBA/IIOP, DCOM/ActiveX, Java, Notes, and Web) are making it feasible to develop standards-based large scale, distributed application systems. These are, however, exploited in a very limited way in the current generation of products.
Workflow management and enterprise application integration techniques developed in the METEOR (Managing End-To-End OpeRations) project at the Large Scale Distributed Information Systems Lab, University of Georgia (UGA-LSDIS) are intended to reliably support large-scale, complex workflow applications in real-world, multi-enterprise heterogeneous computing environments. METEOR supports advanced workflow management capabilities and provides integration capabilities needed to deploy solutions in highly heterogeneous environments. An important aspect of this project is that the technology and system development effort at UGA-LSDIS has occurred in close collaboration with its industry partners. Key healthcare partners have been the Connecticut Healthcare Research and Education Foundation (CHREF), Medical College of Georgia (MCG), and Advanced Technology Institute. The collaborations have involved a detailed study of healthcare workflow application requirements, prototyping of significant healthcare workflow applications with a follow-on trial, and evaluation of METEOR's technology at the partner's location resulting in technology improvement leading to a commercial product from Infocosm, Inc. (see: http://infocosm.com).
In section 2, we discuss current generation software support for healthcare processes and highlight some shortcomings of these systems. Section 3 describes the METEOR System, and section 4 discusses four healthcare workflow applications prototyped using the METEOR System and their requirements. Section 5 summarizes the benefits of the METEOR approach; section 6 reviews future work and concludes the paper.

2. Supporting Healthcare Processes With Current Generation Workflow Systems.


Traditionally, healthcare processes have been managed using some limited forms of workflow. Examples of these are clinical protocols like critical pathways and administrative protocols like those for providing clinical referrals. However, these "protocols have remained limited in their usefulness in part because developers have rarely incorporated both clinical and administrative activities into one comprehensive care protocol. This lack of integration hinders the delivery of care, as the effectiveness of protocols is often dependent on many administrative tasks being properly executed at the correct time" [Chaiken 97]. Consequently, many healthcare organizations are now turning to workflow management techniques to help with improving the efficiency of their work processes.
This trend to computerize business processes has led to a large number of commercially available workflow systems, some of which target specifically the healthcare sector. These systems offer various levels of process support, functionality and robustness. At one end of the spectrum, we have customized workflow application systems that support human-oriented, vertical group processes like patient registration. These processes typically involve relatively a few number of tasks which are executed in a predefined sequence, and require few roles in a single group of an organization. In these types of applications, the process model is embedded in the application and customers may need to configure the application in order to tailor it to their specific process. Some example products are Intrabase's managER with applications to help with patient assessments, patient tracking and guideline driven patient prioritization in the emergency room, Tess Products's Tess System for managing patient billing, filling insurance claims, etc. [Intrabase] These are not general purpose for example they will not have modeling tools to specifiy your process. Another class of applications at this end of the spectrum focus on supporting patient data management functions. These applications are usually built on top of Document Management Systems which are designed to capture, store, retrieve and manage unstructured information objects such as text, spreadsheets, audio clips, images, video, files, multimedia and compound documents which may contain multiple objects types. They are used for things like storage of medical records and patient billing documents. They may also provide email-based routing of such documents.
At the other end of the process support spectrum, we have workflow management systems, which are more general –purpose systems that provide tools for process definition, workflow enactment, and administration and monitoring of workflow processes. The process definition tool allows for organization to explicitly model their specific business process and the workflow enactment system supports the automation of this process by coordinating both the manual (performed by a human) and automated tasks (performed by software applications), and the data flow between the tasks. Scheduling and routing of tasks and data to the appropriate person or resource at the right time is done by the enactment system. Some of the workflow systems vendors are FileNet, IBM, InConcert, Software Ley, StaffWare, TeamWare Group and W4.
Current generation workflow systems adequately support administrative and production workflows, but are less adequate for some of the more horizontal healthcare processes which have more complex requirements. These types of processes are dynamic, involve different types of tasks, human-oriented, legacy applications and database transactions, they cross functional and organizational boundaries where the different groups will have distributed and heterogeneous computing environments. Support for such processes by these systems is limited, because many systems have centralized client server architectures, execute in single platform environments, and support only static processes. They also lack support for features like exception modeling and handling.
Another very important requirement that these systems seldom provide is an integration environment. It is clear that the different functional groups of a healthcare organization may require different types of applications to support their processes. For example, integrating Picture Archiving Systems (PACS) with hospital or radiology information systems will allow for radiologists to be presented with collateral patient information like, patient history, clinical information, symptoms, reasons for presentation and previous examination history, instead of just a number, or name or image. Such information will greatly aid in the interpretation of images [DeJesus 98]. In addition, there will be a lot of legacy applications and workflow systems that are may already be in use in these organizations. This lack of interoperability and integration support is due to the fact that many current generation workflow systems usually are based closed proprietary architectures, and do not support interoperability and integration standards such as CORBA. Some products do provide API for integrating their products with existing systems, however this requires those existing systems to incorporate these API calls in their programs. This, of course, is difficult to do in some cases like with legacy systems where the programs will have to be modified to incorporate these API calls.
The METEOR system was developed specifically to support enterprise wide processes involving workflow support and enterprise integration. Supporting mission-critical enterprise-wide process requirements was exactly the basis for the METEOR architecture.

3 THE METEOR SYSTEM:

The METEOR (Managing End to End OpeRations) system is intended to support complex workflow applications which involve heterogeneous and legacy information systems and hardware/software environments, span multiple organizations, or which require support for more dynamic processes, error handling and recovery. Collaboration with healthcare industry partners is integral to our work, and involves real world application prototyping and METEOR technology evaluation as part of trials conducted by the healthcare and industry partners. METEOR includes all of the necessary components to design, build, deploy, run and monitor workflow applications. METEOR provides four main services:



  • METEOR Builder Service which allows users to graphically specify their workflow process;

  • METEOR Enactment Services: provides two enactment services that support the execution of workflows, ORBWork and WebWork. Both ORBWork and WebWork use a fully distributed open architecture, but WebWork [Miller et.al.] is a comparatively light weight implementation that is well suited for traditional workflow, help-desk, and data exchange applications. ORBWork [Kochut et.al.] is better suited for more demanding, mission-critical enterprise applications requiring high scalability, robustness and dynamic modifications;

  • METEOR Repository Service: provides tools for storage and retrieval of workflow process definitions that may used in the Builder tool for rapid application development, and is also available to the enactment services to provide the necessary information about a workflow application to be enacted;

  • METEOR Manager Services: The management service support monitoring and administering workflow instances as well as configuration and installation of the enactment services.

3.1 METEOR Architecture:

The main components in the execution environment are the Workflow Scheduler, Task Managers and Tasks (Figure 1). To establish global control as well as facilitate recovery and monitoring, the task managers communicate with a scheduler. It is possible for the scheduler to be either centralized or distributed, or even some hybrid between the two [Wan 95, Miller et.al. 96].



Figure 1: METEOR System Architecture



To facilitate monitoring and control of tasks, each task is modeled using a well-defined task structure at the design time. [Attie et.al. 93, RS95, Krishnakumar et.al. 95]. A task structure simply identifies a set of states and the permissible transitions between those states. Several different task structures have been developed – transactional, non-transactional, compound, two-phase commit (2PC) [Krishnakumar et.al. 95, Wan 95].


To more effectively manage complexity, workflows may be composed hierarchically. The top level is the overall workflow, below this are sub-workflows (or compound tasks), which themselves may be made up of sub-workflows or simple tasks. Coordination between tasks is accomplished by specifying intertask dependencies using enable clauses. An enable clause may have any number of predicates. Each predicate is either a task-state vector or a boolean expression. A task-state vector contains the state of all the tasks that are incident on the current task. When one task leaves a given state it may enable another task to enter its next state.
The next sections describe the METEOR components in detail.

3.1.1 METEOR Builder Service:

The METEOR Builder service is used for Process Modeling and Workflow Design. The Process modeling mode focuses on understanding the structure of the business process, and does not consider any details of implementing the process. At the workflow design stage, details that will enable the implementation of the process are added to the process model.


The METEOR Builder Service consists of a number of components that are used to graphically design and specify a workflow. Its three main components are used to specify the entire map of the workflow which express the ordering of tasks in the workflow and the dependencies among them, the data objects manipulated by the workflow, as well as the details of task invocation, respectively. The task design component provides interfaces to external task development tools (e.g., Microsoft’s FrontPage to design the interface of a user task, or a rapid application development tool). This service allows modeling of complex workflow at a level that abstracts the user from the underlying details of the infrastructure or the runtime environment, while imposing very few restrictions the workflow specification. The workflow specification created using this service is stored by the METEOR Repository service and includes all the predecessor-successor dependencies between the tasks as well as the data objects that are passed among the different tasks. It also includes definitions of the data objects, and the details of the task invocation details. The specification may be formatted to be compliant with the Workflow Process Definition Language (WPDL) of the Workflow Management Coalition [WfMC]. This service assumes no particular implementation of the workflow enactment service (runtime system). Its independence from the runtime supports separating the workflow definition from the enactment service on which it will ultimately be installed and used. Detailed information concerning this service (earlier referred to as METEOR Designer, MTDes, is given in [Lin 97, Zheng 97]. The data design component allows the user to specify data objects that are used in the workflow, as well as relationships, e.g. inheritance, aggregation, between the data objects.
A new version of the METEOR Builder service is currently being implemented using Java. This will allow users to interact with process definitions at runtime and specify dynamic changes to specification if needed. The new Builder service also outputs an XML based representation of process definitions. It will also have some additional features like support for exception modeling.

3.1.2 METEOR Enactment Services

The task of the enactment service is to provide an execution environment for processing workflow instances. At present, METEOR provides two different enactment services: ORBWork and WebWork. Each of the two enactment services has a suitable code generator that can be used to build workflow applications from the workflow specifications generated by the building service or those stored in the repository. In the case of ORBWork, the code generator outputs specifications for task schedulers, including task routing information, task invocation details, data object access information, user interface templates, and other necessary data. The code generator also outputs the code necessary to maintain and manipulate data objects created by the data designer. The task invocation details are used to create the corresponding “wrapper” code for incorporating legacy applications with relative ease. Details of code generation for WebWork are presented in [Miller et.al.. 98].


ORBWork addressess a variety of shortcomings found in today’s workflow Systems by supporting the following capabilities:


  • provides an enactment system capable of supporting dynamic workflows,

  • allow significant scalability of the enactment service,

  • support execution over distributed and heterogeneous computing environments within and across enterprises,

  • provide capability of utilizing or integrating with new and legacy enterprise applications and databases 1 in the context of processes,

  • utilize open standards, such as CORBA due to its emergence as an infrastructure of choice for developing distributed object-based, interoperable software,

  • utilize Java for portability and Java with HTTP network accessibility,

  • support existing and emerging workflow interoperability standards, such as JFLOW [JFLOW] and SWAP [SWAP], and

  • provides standard Web browser based user interfaces, both for the workflow end-users/participants as well as administrators of the enactment service and workflows.

One of the design goals of ORBWork has been to provide an enactment framework suitable for supporting dynamic and adaptive workflows. Currently, ORBWork does not concern itself with the issues of correctness of the dynamically introduced changes as those are handled outside of the enactment system. However the architecture of the enactment system has been designed to easily support dynamic changes and serve as a platform for conducting research in the areas of dynamic and collaborative workflows. The use of a fully distributed scheduler in ORBWork warrants the need to provide the scheduling information to all participating task schedulers at runtime. The scheduling information includes details of transitions leading into and out of the schedulers and also the list of data objects to be created.


ORBWork’s scheduler is composed of a number of small schedulers, each of which is responsible for controlling the flow of workflow instances through a single task. The individual schedulers are called task schedulers. In this way, ORBWork implements a fully distributed scheduler in that all of the scheduling functions are spread among the participating task schedulers that are responsible for cooperating task schedulers. Each task scheduler controls the scheduling of the associated task for all of the workflow instances “flowing” through the task. Each task scheduler maintains the necessary task routing information and task invocation details.
At startup each task scheduler requests scheduling data and upon receiving it configures itself accordingly. Furthermore, the configuration of an already deployed workflow is not fixed and can be changed dynamically. At any given time, a workflow designer, or in some permitted cases an end-user, may decide to alter the workflow. The introduced modifications are then converted into the corresponding changes in the specification files and stored in the repository. A “reload specification” signal is then sent to the affected task schedulers. As a result, the schedulers reload their specifications and update their configurations accordingly, effectively implementing change to the existing workflow.
The fully distributed architecture of ORBWork yields significant benefits in the area of scalability already mentioned, all of the workflow components of a designed and deployed workflow may be distributed to different hosts. However, in practice it may be sufficient to deploy groups of less frequently used task scheduler/manager/programs to the same host. At the same time, heavily utilized tasks may be spread out across a number of available workflow hosts, allowing for greater load sharing.
The features of ORBWork designed to handle dynamic workflows are also very useful in supporting scalability As load increases, an ORBWork administrator may elect to move an portion of the currently running workflow to a host (or hosts) that become available for use in the workflow. The migration can be performed at the time the deployed workflow is running. Simply, the workflow administrator may suspend and shutdown a given task scheduler and transfer it to a new host. Because of the way task schedulers locate their successors, the predecessors of the moved task scheduler will not notice the changed location of the task.

The distributed design of ORBWork offers no single point of failure for an ongoing workflow instance. Since the individual task schedulers cooperate in the scheduling of workflow instances, a failure of a single scheduler does not bring the whole system down, and other existing workflow instances may continue execution.


The error handling and recovery framework for ORBWork (initial design has been described in [Worah et.al. 97]) has also been defined in a scalable manner. All errors are organized into error class hierarchies, partitioning the recovery mechanism across local hosts, encapsulating and handling errors and failures as close to the point of origination as possible, and by minimizing the dependence on low –level operating system-specific functionality of the local processing entities.

Details of ORBWork can be found [Kochut et.al. 98].



3.1.3 METEOR’s Repository Service:

The METEOR Repository Service is responsible for maintaining information about workflow definitions and associated workflow applications. The graphical tools in the workflow builder service communicate with the repository service and retrieve, update, and store workflow definitions. The tools are capable of browsing the contents of the repository and incorporating fragments (either sub-workflows or individual tasks) of existing workflow definitions into the one being currently created. The repository service is also available to the enactment service (see below) and provides the necessary information about a workflow application to be started.

The current implementation of the repository service implements the Interface 1 API, as specified by WfMC [WfMC]. A detailed description of the first design and implementation of this service is presented in [Yong 98]

3.1.4 METEOR’s Management Services:

The tools provided by these services are used for administering and monitoring workflows. The METEOR Monitor provides a tool for querying for and viewing the state of workflow instances. The Administration service is used by workflow adminstrator to perform management functions like installing and configuring workflow instances, load-balancing, modifying a workflow process while it is still executing, etc.



4 Significant HealthCare Applications Prototyped Using METEOR

The healthcare sector has a number of different types of organizations. By healthcare sector we mean both hospital and non-hospital based organizations. Examples of non-hospital based organization are the pharmaceutical companies, laboratories, etc.,. All these organizations have different types of processes and different requirements. Table 1 gives a summary of the different types of processes, the applications that support them, and their requirements.




Hospital Based

Processes

Example Applications

Requirements


Clinical


Charting,

Scheduling,

Discharge Summaries,

Reports.


Integration with patient data management software; Management of human and automated activities; Exception handling; Ease of Use; Support for Dynamic Changes; Security; Role-Based Authorization

Non-Clinical

(Administrative and Financial)


Ordering Systems

(radiology, pharmacy)

Patient Management (billing, accounts receivable, claims filing)


Data Management and Integration; Application Integration; Support for Heterogenous and Distributed Environments; Security; Support for standards, EDI, HL7; Exception handling

Non-Hospital

Based

Laboratory



Laboratory Information Systems.

Scalability; Exception handling; Management of complex data types; Transactional Workflows; Integration with other systems; Support for HAD environments

Pharmaceutical Industry

Clinical Drug Trial Management

Distributed Environment; Scalability; Exception Handling

Table 1: Healthcare Processes and Applications
The rest of this section describes four applications that we have prototyped using METEOR. These applications support different types of processes, varying in scale, i.e., number of tasks and roles, and requirements ranging from single server to multiple distributed web servers, workflow execution across different workflow system installations, and integration of legacy applications and databases. The first three applications, Neonatal Clinical Pathways, GeneFlow and Eligibility Referral are briefly sketched, highlighting requirements and implementation strategies.

The fourth application, Immunization Tracking, is a more comprehensive application and is discussed in more detail. (The figures in this section are screen shots from the METEOR Builder Service.)


4.1 Neonatal Clinical Pathways

A low birth-weight baby with underdeveloped organs is normally considered to be at risk for a number of medical problems. To monitor the development of the babies, their development is processed through several clinical pathways. Three of the major pathways are the Head Ultrasound, Metabolic and Immunization pathways. When a human-dependent approach is used for tracking patients, errors occur and some patients fall through the cracks because the necessary tests are not performed on time. To automate the scheduling of procedures at appropriate times and eliminate such errors, a METEOR workflow application was developed for the Neonatal Intensive Care Unit (NICU) at the Medical College of Georgia.

The Figure 2 shows the graphical representation of the Head Ultrasound pathway. Here, an initial ultrasound is done when the baby arrives at the NICU, and is repeated at specified intervals over a period of weeks. The duration depends on whether test results indicate an improvement in the baby’s condition. The application issues reminders for scheduling tests, retrieving test results, and updating patient records, to the nurse responsible for tracking this data.





Figure 2: Head UltraSound Pathway

Requirements

The workflow process involves a single organization, three roles, and a single database. Some of the requirements for this process, like timing or temporal constraints, etc., are not supported by current generation workflow products. Advanced features like support for heterogenous and distributed environments and integration of legacy applications were not requirements here.


Implementation:

This application was developed using the WebWork enactment service of the METEOR system. It is a web enabled client server application that uses a single web server and an Oracle database.

The communication infrastructure between the different tasks within the workflow uses the web, specifically CGI scripts. The end-user interface is a web browser.


Figure 3 : Implementation for NeoNatal Clinical Pathways



4.2 GeneFlow

GeneFlow is being developed specifically for the needs of the Fungal Genome Initiative. This is a multi-institution consortium of research groups which is mapping and sequencing the genomes of important fungal organisms. GeneFlow is a workflow application to handle the needs of data analysis for genome sequencing. Raw "shotgun" DNA sequence data consists of short (< 1500 characters) overlapping DNA sequences. This data comes from automatic sequencing machines. From this raw data the short overlapping shotgun sequences must be synthesized into larger contiguous sequences of whole chromosomes. The sequence from an entire chromosome may be many millions of characters long. These larger sequences are searched for probable genes and other chromosomal features. Probable genes are then analyzed to determine a probable function as well as to identify smaller scale features within the gene. These results then must be electronically published. The end result of all this is a completely annotated genome that is public domain.







Figure 4: Workflow Design for GeneFlow
METEOR tools are being used to wrap genome data analysis applications together in a "genome data assembly line".

Requirements

In this application, multiple and heterogenous servers (SGI, Solaris) are used with a single database and a single workflow system. The process required many human and automated tasks, support for legacy applications and Web-based access to support geographically distributed users.
























Figure 5: System Architecture for Geneflow

Implementation:
This application was also developed using the WebWork. Integration of legacy application on both the Solaris and the SGI servers was done by writing C++ wrappers for the legacy tasks. These wrappers were then easily integrated with the WebWork enactment service.



4.3 Eligibility Referral


The Eligibility Referral Application was developed for the Connecticut Healthcare

Research and Education Foundation (CHREF) to support the process of transferring a patient from one hospital to another. It involves three organizations, two hospitals and an insurance company.

The design depicted in Figure 3 shows a consolidated workflow including both the sending and the receiving hospitals. The workflow starts with the sending hospital trying to determine the right



Figure 6: Eligibility Referral Workflow

placement for the patient that needs to be sent out. Once this is done, the next few tasks involve determining the eligibility information, obtaining the necessary payment information and also getting the physicians signature for the specified patient. The final step in the sending hospitals’ workflow, is to send and receive an acknowledgement from the receiving hospital, indicating that will accepting the patient there. Once this is done the sending hospital can update their database and receiving hospital takes over from there. The receiving hospital also has its own workflow for processing transferred patients.

A workflow instance spans the two hospitals with interaction with the insurance company through EDI transactions.


Figure : 7 Implementation testbed for Eligibility Referral

Requirements

Support for distributed and heterogeneous environments. Workflow execution across multiple installations of the METEOR system. Multiple databases and web-servers. Support for heterogeneous tasks such as human, automated and transactional tasks with EDI transactions.


Implementation:

The sending and receiving hospitals have separate METEOR system installed and a single workflow instance executes across both the hospitals. Each hospital hosts its own web server and a database e.g. the sending hospital needs to find data about the patient to verify eligibility information, to obtain physician signature etc. The same applies to the receiving hospital.




4.4 State-Wide Immunization Tracking Application:

The Immunization Tracking Application has the most advanced requirements of all four examples discussed. With managed healthcare coming of age, performance monitoring such compulsory performance reporting, immunization tracking, childbirth reporting, etc. have become important rating criteria. In fact, the first item listed under Quality of Care in the Health Plan Employer Data and Information Set (HEDIS) [HEDIS] is childhood immunization rate. Healthcare resources must be used efficiently to lower costs while improving the quality of care. To accomplish these goals, processes in the managed healthcare industry need to be computerized and automated.

Figure 8 shows the scope of the application in schematic form. The process

includes on-line interactions for the workflow application between CHREF (as the central

location), healthcare providers (Hospitals, Clinics, home healthcare providers) and user organizations (State Department of Health (SDOH), Schools, Department of Social Services (DSS)).



Figure 8: Schematic for Immunization Tracking Application

The system can be best explained in terms of the following three components, the databases, the Clinical and Tracking Subsystems.


Databases:

The workflow application system supports the maintenance of the following central databases:



  • The Master Patient Index (MPI) records the personal information and medical history of patients.

  • The Master Encounter Index (MEI) records brief information pertaining to each encounter of each patient at any hospital or clinic in the state.

  • An Immunization Database (IMM) records information regarding each immunization performed for a person in the MPI,

  • Eligibility databases (ELG) provides an insurance company’s patient eligibility data, and

  • The Detailed Encounter databases (ENC) provides detailed encounter information as well as relevant data for each patient served by a particular provider.

The current application design and implementation calls for CHREF to manage the MPI, MEI and the IMM centralized databases for the state of Connecticut. The ELG database containing data provided by insurance companies is used in this application for EDI based eligibility verification using the ANSI X12 standard. In particular, Web-based access is used to submit eligibility inquiries using ANSI 270, and responses are received using ANSI 271 “transactions”. Each participating provider organization (hospital or clinic) has its own ENC database. When a structured database is used at CHREF, we promote the use of ODBC compliant DBMS. The DBMS’s (Illustra and Oracle) used in this application are ODBC compliant.



The Clinical SubSystem

The clinical subsystem has been designed to provide the following features:



  • Roles for Admit Clerk, Triage Nurse, Nurse Practitioner and Doctor

  • Worklist for streamlining hospital and clinic operations

  • Automatic generation of Medical Alerts (e.g. delinquent immunizations) and Insurance Eligibility Verification by the Admit Clerk, and

  • Generation of contraindications for patients visiting a hospital or clinic to caution medical personnel regarding procedures that may be performed on the patient.



The Tracking SubSystem

H
Figure 2: Immunization Tracking Application Schematic

ealth agencies can use the data available to generate reports (for submissions to authorities like the DSS, State Government, etc.), and for determining the health needs of the state. More importantly, immunization tracking involves reminding parents and guardians about shots that are

due or overdue and informing field workers about children who have not been receiving their immunizations.




Figure 9: Provider’s Interface for Immunization Recommendation Task


Requirements of the Application
The development of the application was completed with constraints due to end-user and system requirements.

Some of the important requirements for this application, as determined by CHREF, include



  • Support for a distributed client/server-based 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, non transactional user and application

  • Capability for using existing DBMS infrastructure across organizations.

  • Low costs of system for the providers and user organizations

  • Ease of modification (re-design), scalability, extensibility and fast design-to-implementation.

  • Use of standards, including EDI for interactions between autonomous organization where possible

  • Security authorization for user and secure communication (required as patient data is typically confidential)

  • Web-based user interfaces for healthcare personnel such that shown in Figure 9.



F
igure 10: Implementation Testbed for the Immunization Tracking Application

Based on these requirements, we have created a system test-bed on which the application is implemented (figure 10). This includes a heterogeneous communication infrastructure, multiple Web servers, CORBA) and multiple databases. The workflow involves 13 tasks (e.g. tasks for the admit clerk, triage nurse, eligibility check, etc.), heterogeneous computers in Georgia and Connecticut (Web and DBMS servers on Sparc20/Solaris 2.4, Sparc5/Solaris2.4, and personal computers running Windows/NT as well as several PC/Windows95 Clients), and five databases on two DBMS (Illustra, ORACLE).

5 Benefits of the METEOR Approach:

5.1 Advanced capabilities and unique features






Table 2 :Benefits of the METEOR Approach

METEOR offers unique solutions to realize the promise of recent advances in distributed computing infrastructure, middle-ware and Web technologies. By quickly integrating applications and information systems to support complex and dynamic business process management, METEOR provides technical advantages that distinguish it from other systems. These distinctions are outlined in Table 2 for the example applications discussed in Section 4. Additionally, the capabilities are defined fully in following sections.



Automatic Code Generation:

Once the workflow designer has designed the workflow using the METEOR Builder Service, very few additional steps are required to implement the workflow. This is of utmost importance to the designer. If the workflow designer has spent enough time studying the application and designing the workflow, then his job in implementing the workflow reduces to a bare minimum of writing application-specific tasks for the application at hand. This frees the designer from having to worry about the modes of communication or data passing between existing tasks.

For example, the top part of figure 11 shows the graphical design of part of the Immunization Tracking workflow. The bottom part shows the components automatically generated from the top design which include CORBA objects for Task Managers, Task Schedulers and Data Objects, as




Figure 11: Code Generation for the Immunization Tracking Application
well as HTML pages used as user interfaces.


  • A fully distributed System:

One of the important requirements in almost any modern industry is the capability to support machines that are spread across the entire organization. Both of the enactment systems of METEOR have a fully distributed architecture. This provides support for load balancing among all the participating host machines, and also eliminates the existence of a single point of failure within the system.


  • Use of standards and the latest distributed computing infrastructures for heterogeneous environments:

The METEOR System closely follows the standards set by bodies such as the WFMC and the Object Management Group (OMG). For example, the workflow specification created using the METEOR Builder service is XML-based and may easily be formatted to be compliant with the Workflow Process Definition Language (WPDL) of the WFMC. METEOR also supports the workflow interoperability standards such as JFLOW [JFLOW] and SWAP [SWAP]. In addition, METEOR utilizes the open standards, such as CORBA due to its emergence as an infrastructure of choice for developing distributed object-based, interoperable software.


  • Integration capabilities with legacy and new applications, and multiple/heterogeneous remote databases including mainframe data:

The support that METEOR provides in integration of legacy application is a big distinction point for the system. The CORBA based enactment system (ORBWork) is implemented in Java which provides the system with portability and network accessibility. It also uses Java Database Connectivity to connect to a variety of databases and now with the availability of Databroker [I-Kinetics], data from databases that reside on mainframes can easily be integrated with the METEOR system.


  • Security:

METEOR provides various levels of security from role-based access control and authentication to multi-level security as is required in military institutions.

6. Conclusion and Future Directions

Today’s healthcare applications require capabilities for enterprise integration and mission-critical workflow process support. While such functionality is found lacking in many of the current generation workflow systems, the METEOR system distinguishes itself by focusing on supporting these high-end requirements.

The METEOR approach enables rapid design-to-development via automatic code generation; the workflow model and enactment system support a variety of activities - user and application (automated) tasks, thereby making it feasible for use in real-world organizational processes. The workflow engines support heterogeneous, distributed computing environment with standards based computing infrastructure (Web and/or CORBA). This allows workflow process and data to be distributed within and across enterprises. Reliability is an inherent part of the WFMS infrastructure. The WFMS includes support for error handling and recovery by exploiting transaction management technology. A well-defined hierarchical error-model is used for capturing and defining logical errors, and a recovery framework provides support for detection and recovery of workflow system components in the event of failure.

Currently, the METEOR project group is working to extend the system in a number of ways.



  1. The development to an interactive Java-based Builder Service, which renders XML-based workflow descriptions, allows users to modify workflow definitions at run time, and has ability to validate workflow specification at design time.

  2. Extend process support to include collaboration by integrating with technologies like video-conferencing.

  3. Currently, METEOR provides task managers for task functionality at a high level of granularity e.g., Transactional Task Manager for Database transaction tasks, Human-Computer Task Manager for computer assisted human tasks, etc. We are considering implementing the Task Managers based on Enterprise JavaBeans technology. This will enable support for a wide variety of function specific tasks, e.g. a Task Manager for EDI tasks.

  4. Incorporate advanced exception handling techniques like defeasible workflow and cased-based reasoning [ Luo et.al. 98].



Acknowledgements

METEOR team consists of Kemafor Anyanwu, Ketan Bhukhanwala, Jorge Cardoso, Prof. Krys Kochut (co-PI), Zhongqiao Li, Zonghwei Luo, Prof. John Miller (co-PI), Kshitij Shah, Prof. Amit Sheth (PI), Key past contributors include: Souvik Das, David Lin, Arun Murugan, Devanand Palaniswami, Richard Wang, Devashish Worah, and Ke Zheng.


This research was partially done under a cooperative agreement between the National Institute of Standards and Technology Advanced Technology Program (under the HIIT contract, number 70NANB5H1011) and the Healthcare Open System and Trials, Inc. consortium. See URL: http://www.scra.org/hiit.html. Additional partial support and donations are provided by Iona, Informix, Hewlett-Packard Labs, and Boeing.
Bibliography:
[Attie et.al. 93] P. Attie, M. Singh., A. Sheth., M. Rusinkiewicz., Specifying and Enforcing Intertask Dependencies “, in Proc. of the 19th Intl. Conf. on Very Large Data Bases, August, 1993
[Bonner et.al.. 96] A. Bonner, A. Shruf, S. Rozen, “Database Requirements for Workflow Management in a High-Throughput Genome Laboratory”. In Proceedings of the NSF Workshop on Workflow and Process Automation in Information Systems: State-of-the-Art and Future Directions. May, 1996

[Chaiken 97] B.Chaiken,“Workflow in Healthcare”, http://www.araxsys.com/araxsys/resources/workflow.pdf


[Cichocki et.al.. 97] A. Cichocki and M. Rusinkiewicz, “Migrating Workflows”, Advances in Workflow Management Systems and Interoperability, Istanbul, Turkey, August 1997.
[Das et.al.. +97] S. Das, K. Kochut, J. Miller, A. Sheth, and D. Worah, ORBWork: A Reliable Distributed CORBA-based Workflow Enactment System for METEOR2, Technical Report UGA-CS-TR-97-001, LSDIS Lab, CS Department, Univ. of Georgia, February 1997.
[Dayal et.al.. 91] U. Dayal, M. Hsu, and Ladin, R. “A Transactional Model for Long-running Activities. In Proceedings of the Sixteenth International Conference on Very Large Databases, pg 113-122, August 1991
[DeJesus 98] X. DeJesus, “Integrating PACS Power, Healthcare Informatics”, Vol. 15, (20), pg. 97. November 1998

[Ellis et.al.. 95] C. Ellis, K. Keddara, and G. Rozenberg, “Dynamic Changes within Workflow Systems”, In Proc. of the Conf. on Organizational Computing Systems (COOCS’95)}, 1995.


[Georgakopoulos et.al.. 95] D. Georgakopoulos, M. Hornick and A. Sheth, “An Overview of Workflow Management: From Process Modeling to Infrastructure for Automation”, Journal on Distributed and Parallel Database Systems, 3 (2), 1995
[Guimaraes et.al.. 97] N. Guimaraes, P. Antunes, and A. Pereira, The Integration of Workflow Systems and Collaboration Tools, Advances in Workflow Management Systems and Interoperability, Istanbul, Turkey, August 1997.
[Han 97] Y. Han, "HOON - A Formalism Supporting Adaptive Workflows," Technical Report #UGA-CS-TR-97-005, Department of Computer Science, University of Georgia, November 1997.
[Han et.al. 98] Y. Han and A. Sheth, "On Adaptive Workflow Modeling," the 4th International Conference on Information Systems Analysis and Synthesis, Orlando, Florida, July, 1998
[Hermann 95] T. Hermann, Workflow Management Systems: Ensuring Organizational Flexibility by Possibilities of Adaptation and Negotiation, In Proceedings of the Conference on Organizational Computing Systems (COOCS’95)}, 1995.
[Jablonski et.al.. 97] S. Jablonski, K. Stein, and M. Teschke, Experiences in Workflow Management for Scientific Computing, In Proceedings of the Workshop on Workflow Management in Scientific and Engineering Applications (at DEXA97), Toulouse, France, September 1997.
[Kaldoudi et.al. 97] E. Kaldoudi, M. Zikos, E. Leisch, and S.C. Orphanoudakis, Agent-Based Workflow Processing for Functional Integration and Process Re-engineering in the Health Care Domain, in Proceedings of EuroPACS’97, Pisa, Italy pp. 247-250 September , 1997

[Kochut et.al.. 98] K. Kochut, A. Sheth, J. Miller, "ORBWork: a CORBA-Based Fully distributed, Scalable and Dynamic Workflow Enactment Service for METEOR," Technical Report UGA-CS-TR-98-006, Department of Computer Science, University of Georgia, 1998.


[Krishnakumar et.al. 95] N. Krishnakumar and A. Sheth, “Managing Heterogeneous Multi-system Tasks to Support Enterprise-wide Operations,” Distributed and Parallel Databases Journal, 3 (2), April 1995
[Infocosm] Infocosm home page, http://infocosm.com
[Intrabase] Intrabase home page, http://www.intrabase.com/
[JFLOW] OMG jFlow Submission, ftp://ftp.omg.org/pub/docs/bom/98-06-07.pdf
[Lin 97] C. Lin, “A Portable Graphic Workflow Designer,” M.S. Thesis, Department of Computer Science, University of Georgia, May 1997.
[Luo et.al. 98] Z. Luo, A. Sheth, J. Miller, K. Kochut, “Defeasible Workflow, Its Computation and Exception Handling”, CSCW 98, Towards Adaptive Workflow Systems Workshop, Seattle, WA. 1998.
[Marietti 98] C. Marietti, “Love V Love? Hardly, as ActiveX and CORBA volley for Leadership.” Healthcare Informatics, Vol. 15, (20), pg. 56. November 1998
[McClatchey et.al.. 97] R. McClatchey, J. M. Le Geoff, N. Baker, W. Harris, and Z. Kovacs, A Distributed Workflow and Product Data Management Application for the Construction of Large Scale Scientific Apparatus, Advances in Workflow Management Systems and Interoperability}, Istanbul, Turkey, August 1997.
[MEDITECH] MEDITECH home page, http://www.meditech.com
[METEOR] METEOR project home page, http://lsdis.cs.uga.edu/proj/METEOR/METEOR.html
[Miller et.al. 96] J. Miller, A. Sheth, K. Kochut, and X. Wang,. “CORBA­based Run Time Architectures for Workflow Management Systems”. Journal of Database Management,

Special Issue on Multidatases, 7(1), 1996.



[Miller et.al.. 98] J. Miller, D. Palaniswami, A. Sheth, K. Kochut, H. Singh “WebWork: METEOR’s Web-based Workflow Management System”, Journal of Intelligent Information Systems, (JIIS) Vol. 10 (2), March 1998.
[Reichert et.al. 98] M. Reichert and P. Dadam, “ADEPT flex: Supporting Dynamic Changes of Workflows Without Losing Control”, Journal of Intelligent Information Systems, 10 (2), March 1998.
[Sheth et.al.. 1998] A. Sheth and K. Kochut, “Workflow Applications to Research Agenda: Scalable and Dynamic Work Coordination and Collaboration Systems”, in Workflow management Systems and Interoperability, A. Dogac et.al. (eds), Springer Verlag, 1998
[Sheth 97] A. Sheth, “From Contemporary Workflow Process Automation to Adaptive and Dynamic Work Activity Coordination and Collaboration,” Proceedings of the Workshop on Workflows in Scientific and Engineering Applications, Toulouse, France, September 1997.
[Sheth et.al.. 96] A. Sheth, D. Georgakopoulos, S. Joosten, M. Rusinkiewicz, W. Scacchi, J. Wileden, and A. Wolf, Eds. Report from the NSF Workshop on Workflow and Process Automation in Information Systems, Technical Report UGA-CS-TR-96-003, Dept. of Computer Sc., University of Georgia, October 1996. http://lsdis.cs.uga.edu/lib/lib.html
[Sheth et.al. 97] A Sheth, D. Worah, K. Kochut, J. Miller, K. Zheng, D. Palaniswami, S. Das, "The METEOR Workflow Management System and its use in Prototyping Healthcare Applications", In Proceedings of the Towards An Electronic Patient Record(TEPR'97) Conference, April 1997, Nashville, TN.
[Sheth and Kochut 98] A. Sheth and K. Kochut, “Workflow Applications to Research Agenda: Scalable and Dynamic Work Coordination and Collaboration Systems,” in A. Dogac, L. Kalinechenko, T. Ozsu and A. Sheth, Eds. Workflow Management Systems and Interoperability, NATO ASI Series F, Vol. 164, Springer Verlag, 1998.
[SQL*Flow] 170 Systems home page, http://www.170systems.com/sqlflow.htm
[SWAP] Simple Workflow Access Protocol home page, http://www.ics.uci.edu/~ietfswap/index.html
[Taylor 97] R. Taylor, Endeavors: “Useful Workflow Meets Powerful Process”, Information and Computer Science Research Symposium, University of California at Irvine, February 1997. URL: http://www.ics.uci.edu/endeavors/
[WfMC] Workflow Management Coalition Standards, http://www.aiim.org/wfmc/mainframe.htm
[Worah et.al. 97] D. Worah, A. Sheth, K. Kochut, J. Miller, "An Error Handling Framework for the ORBWork Workflow Enactment Service of METEOR," Technical Report, LSDIS Lab. Dept. of Computer Science, Univ. of Georgia, June 1997.
[Yong 98] J. Yong, "The Respository system of METEOR workflow management system", Master Thesis, Department of Computer Science, University of Georgia, March 1998.
[Zheng 97] K. Zheng, “Designing Workflow Processes in METEOR”2 Workflow Management System M.S. Thesis, LSDIS Lab, Computer Science Department, University of Georgia, June 1997.


1 Data integration capability is supported by integrating METEOR’s enactment services with I-Kinetics’s DataBroker/OpenJDBC, a CORBA and Java based middleware for accessing heterogeneous and legacy data sources.






Share with your friends:


The database is protected by copyright ©dentisty.org 2019
send message

    Main page