Using UICDS to Share Data in the Real-time Decision Support System for Pandemic Response

Size: px
Start display at page:

Download "Using UICDS to Share Data in the Real-time Decision Support System for Pandemic Response"

Transcription

1 Using UICDS to Share Data in the Real-time Decision Support System for Pandemic Response Robert Kelley Anup Kumar ABSTRACT This paper presents our experience using the Unified Incident Command Decision Support System (UICDS) middleware platform developed by the US Department of Homeland Security to facilitate sharing data between our Real-Time Decision Support System (RTDSS) and third party data sources We describe the basics of UICDS and further show how we integrated UICDS one of our projects Keywords Messaging frameworks, pandemic response, healthcare data, UICDS 1 INTRODUCTION The Real-time Decision Support System (RTDSS) for Healthcare and Public Health Sector Protection project is collaboration between several universities the Kentucky and Missouri; the goal of the project is to develop a decision support system to provide pandemic response staff decision support tools to assist them with managing the response The RTDSS consists of three primary components, the Pandemic Decision Support System (PanDSS), a Unified Incident Command and Decision Support (UICDS) core, and third-party data source(s) which we briefly introduce here (see Fig 1) The Pandemic Decision Support System (PanDSS) PanDSS is a web-based decision support system that encapsulates the proprietary decision models developed by our team Some of these models include, but are not limited to patient allocation and medical supply inventory allocation The PanDSS is the core of the RTDSS where Aman Gupta amangupta@louisvilleedu Sunderesh Heragu sheragu@louisvilleedu the majority of the model and application processing occur Third-Party Data Source The decision support modules in the PanDSS require often data from other systems that are inputs to the models RTDSS is designed to extract data from third party systems and which is forwarded to a UICDS core from where it can be shared with the PanDSS The Unified Incident Command and Decision Support Core A UICDS core is a system that sends and retrieves data packages known as work products from disparate data sources It provides a middleware for data sharing between systems that were not originally designed to share UICDS is presented in more detail in Section 2 Fig 1: High Level Architecture of the RTDSS This report is organized as follows: Section 2 describes UICDS and presents its basic design and architecture and Section 3 shows how we integrated UICDS into the RTDSS Finally, Section 4 presents our conclusions and future work

2 2 UICDS UICDS was developed by the Department of Homeland Security for sharing emergency management incident information across various governmental and disaster response agencies[1] It uses a service-oriented architecture (SOA) core server to transmit and receive standardized Extensible Markup Language (XML) documents that contain information regarding emergency management incidents (eg fire, tornado, pandemic, etc) Applications that share data through a UICDS core server read and write UICDS compliant messages; for applications that cannot generate or process UICDS messages, adapters (agents) are written to extract, appropriately format and send data (see Fig 2) interact with or use (eg a person, an agency, equipment, etc) NIEM is comprised of numerous schemas that define data elements for various domains and objects (see Error! Reference source not found) The basic unit of work in UICDS is a work product, which represents the data an application wants to share through a UICDS core In essence, an application publishes a work product to the core which is then made available for other applications who might wish to view it (see Fig 3) Fig 2: UICDS Application Interactions Agencies subscribe to core UICDS servers to receive updates and data from various systems involved in the response UICDS messages are built from National Information Exchange Model (NIEM) standard XML schemas NIEM is a collaborative information exchange framework developed in partnership between US Department of Homeland Security and the US Department of Justice to provide standards for formatting data that multiple agencies need to share NIEM originated from the Global Justice XML Data Model (GJXDM); it currently supports data sharing for the justice, public safety, emergency and disaster management, intelligence, and homeland security sectors [2] UICDS supports three categories of work products The first category is the officially recognized UICDS set of work products (eg Notifications, Alerts, Resource Management, Map Service, etc) These work products are typically used to manage the UICDS core and to set up/remove incidents The second category is the XML work product, which is the primary method for an application to encapsulate its own data The third category is the binary work product, which supports sharing objects in proprietary binary formats (eg Word documents, photographs, audio files) Complex interactions between applications can be conducted through UICDS including multiple distributed applications that update a work product and notification services in which various systems are notified when changes to a work product have occurred More information regarding various work products can be found in [3] NIEM schemas are built from data components, which are the fundamental building block Data components represent different objects and entities that agencies

3 Fig 3: Work Product Flow 3 INTEGRATING UICDS INTO RTDSS The PanDSS component of RTDSS is responsible for executing the decision support models developed by our team The PanDSS consists of several different models for medical supply logistics; inventory allocation and management; patient allocation; disease spread; ambulance routing; and emergency department simulations Providing details of all of these models is beyond the scope of this paper However, to provide context, the next section presents the data acquisition process for the patient allocation model (PAM) The PAM is designed to help pandemic response personnel decide which hospitals should accept which patients 31 Patient Allocation Model During a pandemic outbreak, hospitals will be overwhelmed by the patient surge demand It is important to prepare response plans to react to a pandemic influenza outbreak, which cannot be accomplished by hospitals individually, and require collaboration among hospitals both in planning and in response The Patient Allocation Model employs optimization models to help decision makers address the patient and resource allocation issues faced by a multi-facility healthcare network in a medium term influenza outbreak Based on these predictions, decision makers can determine if healthcare facilities need to increase medical capacity, or request additional capacity from the state or national stockpile, which is designed to supplement and re-supply healthcare facilities and state or local public health agencies in the event of an emergency 3 The total number of adult ICU beds the facility contains 4 The number of available adult ICU beds that are ready for patient placement 5 The total number of ventilators the facility contains 6 The number of available ventilators that are ready for patient placement 7 The number of doctors on duty in all departments of the facility 8 The number of nurses on duty in all departments of the facility Most hospitals often store this data in their hospital information systems Moreover, communities typically support sharing this data between hospitals to coordinate effective response to community or region-wide disasters For our pilot system, the region uses WebEOC, which is a proprietary system that allows end-users to develop webbased status boards that emergency personnel use to monitor the status of incidents, request resources, allocate resources, etc [4] Specifically, the instance of WebEOC used by the pilot region hosts a status board for each hospital in the region that contains basic data about each facility s contact information, infrastructure condition This information is updated on a regular basis, less often (bi-weekly) during normal operating conditions, more often (twice daily) during a medical surge WebEOC does not support UICDS messages directly, therefore we wrote an agent that extracts data from WebEOC, packages it into a UICDS message format and forwards to the core (see Fig 4) The agent is configurable so that it collects data from WebEOC at any time interval necessary for the current situation During normal operations, the agent may pull data once a week while during a pandemic or other surge event, it can pull it once an hour The resources of interest for each hospital that have been identified for this model include: 1 The total number of medical/surgical beds the facility contains 2 The number of medical /surgical beds that are ready for patient placement

4 schema will be produced for a later deliverable that can be used to validate this format to ensure it conforms to the standard Fig 4: RTDSS Data Flow Diagram Work products in UICDS are published to the core using an XML message called PublishProductRequest that is encapsulated into a SOAP envelope for HTTP transfer over the Internet (see Fig 6) This XML document contains several sections including the SOAP envelope which is the enclosing document for transmitting the document over HTTP; the PublishWorkProductRequest and its metadata, which includes information about the work product (eg name, ID, timestamp, etc), and finally the payload, which contains the data the application wants to share For the RTDSS, the data contains the Hospital XML File previously discussed The underlying message shared by the UICDS core between WebEOC and the PanDSS is an XML document that contains the basic geographic and resource information for each hospital (see Fig 5) <Hospitals> <Hospital> <OrganizationID></OrganizationID> <name> </name> <address></address> <lat></lat> <lng></lng> <county> </county> <code> </code> <baselinemedsurgebeds></baselinemedsurgebeds> <availablemedsurgebeds></availablemedsurgebeds> <baselineadulticu></baselineadulticu> <availableadulticubeds></availableadulticubeds> <baselinevents></baselinevents> <availablevents></availablevents> <docnum></docnum> <nursenum></nursenum> </Hospital> </Hospitals> Fig 5: Hospital Data XML Format for the Patient Allocation Model and the Hospital Mapping Utility The root-level element of the work product is <Hospitals> which represents a collection of hospitals that will be mapped with the Hospital Mapping Utility or that will be used as inputs for the Patient Allocation model The root element may only appear once, while the sub-element <Hospital> may occur multiple times, once for each hospital in the collection Each of the elements in <Hospital> may only appear once in an instance of <Hospital> and all are required A standardized XML Fig 6: PublishProductRequest SOAP Message for RTDSS/UICDS For security, HTTPS can be used instead of HTTP so work products are encrypted during transfer This can be configured on application requirements 5 CONCLUSION AND FUTURE WORK Our experience working with UICDS has been quite positive We originally intended to write our own messaging framework for our project; UICDS vitiated the need to do this and allowed us to focus more on the development of our project rather than infrastructure code The learning curve for getting up to speed on the UICDS core and the data formats it supports is reasonable Those experienced with service oriented architectures, should be able to implement it quickly

5 While our project currently only has one model that is using UICDS, in the coming months we will implement additional models that will also retrieve data from the UICDS core Moreover, adding additional data sources is simple because the communications infrastructure is already in place Acknowledgements Funding provided in support of community and business resilience by the Kentucky Critical Infrastructure Protection Program, managed by The National Institute For Hometown Security for the US Department of Homeland Security REFERENCES [1] J W Morentz, "Unified Incident Command and Decision Support (UICDS): A Department of Homeland Security Initiative in Information Sharing," in Technologies for Homeland Security, 2008 IEEE Conference on, 2008, pp [2] Introduction to NIEM Available: [3] "UICDS Getting Started Guide," Science Application International Corporation, Arlington, VA2010 [4] ESi911 - WebEOC Available: