abstract
Public Health (PH) applications in County of Los Angeles (LAC), Department of PH have been developed to meet individual PH program’s goals. This resulted in lack of county-wide PH data integration, efficiency, and usefulness. LAC encouraged the development of web-based applications utilizing standards-based PH Information Network interoperable service-oriented architecture (SOA). The goal was to stop the evolution of fragmented health data systems which place limitations on the PH mission of safeguarding and improving the health of the community as well as responding to large-scale threats to PH. PH Nursing case management is one example of LAC’s initiative for promotion of web-based tools which will be utilized within this SOA. This PH architecture is capable of supporting electronic data exchange from PH partners using a HL7 integration hub. It promotes the development of management tools and applications to assist PH response and recovery activities while providing resources to support departmental integration.
introduction
Public health applications in the County of Los Angeles, Department of Public Health have been traditionally developed to assist public health programs in meeting individual program’s goals and objectives. This led to the development of systems that collect data only for a specific program area leading to a lack of county-wide public health data integration, efficiency, and usefulness. The existing Program Area Modules (PAMs) do not conform to the National Electronic Disease Surveillance System (NEDSS) nor Public Health Information Network (PHIN) standards recommended by the Centers for Disease Control and Prevention’s (CDC, US Govt.) for an interoperable information systems in organizations that participate in public health (Public Health Information Network, 2004; National Electronic Disease Surveillance System, 2004).
The PAMs use a variety of user interfaces, business logic, directory structures, workflow, and data storage systems and are not accessible outside public health firewall. The user and electronic interface for these modules have been implemented differently and do not present a common user or electronic interface for these modules, thereby significantly increasing the cost of data collection and analysis. These modules exist as stand-alone entities each with functionality for disease reporting, incident management, and data storage for specific program areas, and in most cases do not communicate at all with each other or external healthcare partners. A limited number of modules have ad-hoc implementation for electronic data exchange with laboratories as well as some other capabilities needed by the application users.
It was determined that under the standards based architecture, PAMs only handle specialized functionality for each specific area of health care or resource management. All common functionality like user authentication, directory serices, data storage, and so on should be handled by Common
Area Modules (CAMs), modules common to all PAMs. An internal message and data broker module will be used for electronic data transfer with partner systems. This initiative will also require that existing investments in legacy systems be leveraged and merged with standards-based Web enabled systems to provide a synchronized view of public health data and resources across all program areas.
The nursing practice management system (NPMS) case management PAM is an example of the Los Angeles County’s initiative in promotion of Web-based tools which is to be utilized within the interoperable standards based architecture. This PAM has won several awards since it was implemented including the Los Angeles County Public Health Innovation Award in 2003 and the National Association of Counties Nursing Achievement Award in 2004 (see Figure 1).
The public health nursing unit of Los Angeles County promotes the well being of the community at large and prevents disease, disability, and premature death. Public health nurses (PHNs) make home visits to families with communicable diseases; emphasize nutrition, disease prevention, and health; and improve the quality of neighborhood life by working in partnership with the community. This system tracks multiple interventions given over a period of time by index case, family, and household. It provides a powerful and secure departmental work-flow, assignment/task management and reporting tool with an intuitive interface design that minimizes training and transition costs. The “open” architecture allows the system to communicate with other Public Health programs. This system involves epidemiological data entry during assessments of cases by Public Health Nurses and serves as an efficient tracking system for nurses and supervisors, ensuring that members of the community are assessed and that interventions are made in a timely manner.
The investment into the approach for an enterprise architecture within an existing infrastructure was done with the view that investment of pre existing assets which include people, facilities, and services must now also include information technology as an asset. It was important for County personnel to determine that services must be governed similar to business returns in the corporate environment for maximal return on investment. The decision to implement this architecture was done keeping in mind that there would be large scale reuse of preexisting programs, improved flexibility for change management and improved comprehensibility of software functionality for a clear relationship between services and function (Sprott, 2004)
Figure 1. The Public Health Nursing Unit of the Department of Public Health, Los Angeles County pro -motes the well being of the community at large and prevents disease, disability, and premature death. This system tracks multiple interventions given over a period of time by index case, family, and household. The “open” architecture allows the system to communicate with other Public Health programs.
To help alleviate the evolution of these separate, fragmented public health data systems which over a period of time place limitations on local public health agencies to accomplish the mission of safeguarding and improving the health of the community and to respond effectively to large-scale threats to public health, the County of Los Angeles has been promoting the development of Web-based applications which will utilize a standards-based interoperable service-oriented architecture (SOA).
Service-oriented modeling and architecture was announced by IBM as the first SOA-related methodology in 2004 (IBM, 2005; Arsanjani, 2004). Since 2004, efforts have been made to move towards greater standardization and the involvement of business objectives.
SOA can also be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services (Tsai, Chen, & Fan, 2006). These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA based systems can therefore be independent of development technologies and platforms (such as Java, .NET etc). In addition, applications running on either platform can consume services running on the other as Web services (Utschig, Rodriguez, & Buelow, 2006).
The Service Oriented Model is a complex architectural models and it revolves around a few key ideas (Spewak & Hill, 1992). A service is realized by one agent and used by a different agent. Services are mediated by means of the messages exchanged between requester agents and provider agents.
Another important aspect of services is their relationship to the real world: services are mostly deployed to offer functionality in the real world. We model this by elaborating on the concept of a service’s owner—which, whether it is a person or an organization, has a real world responsibility for the service. In addition, Service Oriented Model makes use of meta-data, which is a key property of Service Oriented Architectures. This meta-data is used to document many aspects of services: from the details of the interface and transport binding to the semantics of the service and what policy restrictions there may be on the service.
SOA is a mechanism for defining business services and operating models and therefore providing a structure for information technology to deliver the actual business requirements and adapt in a similar way to the business needs (Utschig, Rodriguez, & Buelow, 2006). The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures (Spewak & Hill, 1992).
SOA has also faced some criticisms including concern that Web Services standards and products are still evolving (e.g., transaction, security), and SOA can thus introduce risk unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work (Utschig, Rodriguez, & Buelow, 2006). Web services are designed to support interoperable ma chine-to-machine interaction over a network. Web Service has an interface which can be processed by a machine in a specific format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards
architecture
The Los Angeles County Operational Data Store (LAC-ODS) architecture is based upon recommendations of the Public Health Information Network (PHIN) initiative by Centers for Disease Control (CDC).
In order to maximize the use of pre-existing applications and bring together interoperability the architecture was developed for utilization of the common services while promoting interfaces to new systems with minimal impact on existing systems (LACDHS, 2003).
The architectural design was developed from the premise that change within the county environment is a fact of life and process. The County of Los Angeles continues to provide comprehensive public health programs and services over 17 million people. Therefore the approach to the architecture was to lay out a foundation which could handle change management while stressing on functions and interoperability. The need to reuse preexisting software applications was a major need since this would enable a more effective support of this initiative with greater inputs from the users. The technology capabilities were targeted to be implemented phase wise in order to have optimal feedback and collaborative construction of the architecture (Schuschel & Weske, 2004).
The primary focus of the architecture also kept in mind that the architecture should focus on the services rather than the application. This was done keeping in mind that there was care to adopt a broader scope from building from an existing infrastructure so that an open and flexible architecture on which applications and services can be run. This also eliminated the dependencies on databases supported by vendors. The flexibility of the architecture was ensured by adoption of standard technologies for all layers of the architecture and the messaging itself. There was care taken to design a modularized system to ensure services continuity (LACDHS, 2005).
The decision was to have HL7 RIM V3 as the messaging format for this architecture (Mead, 2005; Regio & Greenfield, 2006). HL7 is a healthcare standard for messaging which is widely being adopted by healthcare and related service providers in their initiative for unified interoperable electronic health standards and implementation of nation wide Electronic Health records. HL7 V3 is currently implemented in UK, Netherlands, Canada, Mexico, Croatia and Germany. Within the US agencies such as Centers for Disease control, Food and Drug Administration and Veterans Administration have adopted the V3 for large scale integration. The messaging included a layer of abstraction in the form of an intermediate XML format. There was a multi version support of the application for database structure and application behaviors for easy change/upgrade and switching functionalities. We created a clearly defined mapping from the physical data model onto the logical data model and from the triggers used by the application to those used in the interfaces. The messaging hub has robust tracking and logging system, which logs everything (including wrappers, etc.) that which is actually send/received is crucial. The design also addressed issues related to failure of real-time interaction and how the message would be handled for receipt and delivery of message. There was also consideration of data synchronization for queries, queues, and so forth (Klein, 2005).
The scope and function of each of the architectural components is as follows (see Figure 2):
1. Authentication and Authorization. This portion of the architecture provides technologies and processes used to authenticate users and authorize their access to system applications and resources. Authentication uses a LDAP implementation to authorize personnel and resources to access application system. The directory includes identification, demographic, and authentication credentials for each registered system user. Upon entry to any of the public health applications the user is prompted to provide their identification data and authorization credentials. Upon verification of the authentication credentials for the identified user access is granted to applications for which the authenticated user is authorized.
2. Health Alert Network (HAN). This portion of the architecture provides technologies and processes used to communicate notifications, warnings, and alerts. The alerts may be initiated by an authorized user or by detection of triggering events within application systems. A personnel directory is used to maintain the identification, demographics, and communication addresses for potential alert recipients. A customizable set of rules is used to determine the appropriate communication mode to use for a given type of alert (telephone, email, pager, or fax) and to determine the escalation required for communications that are not acknowledged by the recipient within a predetermined threshold of time.
3. PHIMS Inbound Message Processing. This portion of the architecture provides the technologies and processes necessary to receive data electronically from external partners (e.g., Hospitals, Laboratories, and Physician Offices) and internal application systems. The inbound message processing component is configured to accept data in a variety of standard and proprietary formats. Supported standard formats include HL7 v2, v3and CDA, X12, and NCPDP. Proprietary formats include any form of ASCII file including XML documents, delimited and non-delimited flat files, and encapsulated files such as PDFs and images. Data are extracted from inbound transactions and placed into a staging area for use in importing into the Operational Data Store (ODS) and creation of outbound messages.
Figure 2. This figure details the existing functional program area modules shown as examples. The inbound and outbound messaging components relationship with the functional program area modules is clearly depicted and shows their role as the communication bus for all data interchange.
4. PHIMS Outbound Message Processing. This portion of the architecture provides the technologies and processes necessary to send data electronically to external partners (e.g., Hospitals, Laboratories, and Physician Offices) and other application systems. The outbound message processing component is configured to create outbound transactions in a variety of standard and proprietary formats depending upon the requirements of the receiving application. Supported standard formats include HL7 v2, v3, and CDA, X12, and NCPDP. Proprietary formats include any form of ASCII data file. Data for outbound transactions are retrieved from a staging area populated from the operational data store (ODS) or directly from functional area modules. Outbound message processing transforms the data in the staging areas into the appropriate transaction format for the recipient.
5. Knowledge Management System (KMS). This component of the architecture provides the technologies and processes necessary to maintain coded terminologies and lexicons used in inbound and outbound messages, the ODS, and functional area modules. The KMS component is configured to import clinical terminologies such as SNOMED,
LOINC, and CPT as well as proprietary coding systems. Linkages are maintained between coded terminologies that facilitate the translation of codes from one terminology to another as well as provide a knowledgebase for use in rules processing, inference logic, and workflow management.
6. Public Health Datamart. This component of the architecture provides the technologies and processes necessary to extract, transform, and load data from the ODS and inbound message staging area into a star-schema based data structure used for analytical reporting. The data mart is a collection of fact tables and conforming dimension tables designed to provide an integrated multidimensional view of public health data. Common dimensions include factors such as time, location, demographics, and organization. Facts include items such cases, admissions, and observations.
7. Business Intelligence Environment (Public Health Dashboard). This component of the architecture provides the technologies and processes necessary to provide access to data in the datamart for use in analysis and visualization. The Business Intelligence Environment included multidimensional analysis tools, statistical tools, and geo-mapping tools to provide a comprehensive view of public health data. The Business Intelligence Environment includes a public health dashboard application that provides a set of measures declared by county management to be of greatest interest, quick links to information of interest, and Web services that expose information from other PAMs and external serices. Users of the dashboard application can drill down into the numbers which influence the measures from there they can slice, dice, and pivot the data as needed. The mapping software enables the data to be plotted on maps that can also be drilled and customized to fulfill a particular analytical need.
8. Operational Data Store. This component of the architecture provides the technologies and processes necessary to integrate data from inbound processing and functional area modules into a single data store. The design of the ODS is based upon the Health Level Seven (HL7) Reference Information Model (RIM). The data store is highly abstracted allowing it to collect any data that can be mapped to the entity, role, participation, act paradigm of the HL7 RIM. Data to be imported into the ODS are first placed into a staging area and are then transformed and imported into the ODS. An ODS API is under construction. The API will accept any HL7 v3 styled transactions and generate RIM objects. The RIM objects are then stored in the ODS using ORM software (i.e., Hibernate). The API will simplify the importing of data into the ODS. Inbound messages of any type can be transformed into HL7 v3 styled transactions and automatically mapped for import into the ODS.
9. Functional Area Modules (PAMS, CAMS and Shared Services). This component of the architecture is the most essential. The functional area modules include the applications, common routines, and services used to address tactical public health information processing requirements. Applications such as communicable disease reporting, nursing practice management, and laboratory information management make up the functional area modules as well as services such as geo-coding, identity managements, and record locator.
IMPLEMENTATION
An Enterprise Service Bus (ESB) for used for our deployment of SOA at the County of Los Angeles. The deployment of the SOA required the conversion of existing systems into services. The task involved in achieving this SOA is ongoing for each system and a common set of components (HAN, CAMS, and Shared Services, etc.) are providing additional functionality (such as security and auditing). The bus is a collection of servers and components that will provide functions and set of tools to assist in the conversion of existing systems to functional services.
The SOA implemented in County of Los Angeles used the following major steps and technologies: Existing systems were used core services and business services were derived from these core services. In turn, process modeling was derived from the business services. Microsoft Technologies such as Microsoft.NET and Web Services, Microsoft BizTalk Server and Web Services Enhancements for .NET were utilized for this implementation.
Microsoft BizTalk was used for PHIMS inbound and outbound message processing and transformation. Microsoft SQL Server is used as the relational database management system for the integrated data repository designed after the Public Health Logical Data Model (PHLDM) and the Health Level Seven Reference Information Model (HL7 RIM). COGNOS and ESRI solutions are used to provide multi-dimensional online analytical processing (MOLAP) in a business intelligence environment that supports GIS, statistical analysis, and reporting. Information standards used within the architecture include HL7 Version 2 ADT and ORU messages; HL7 Version 3 RIM, Vocabulary, and data type specifications; and the Common Alerting Protocol (CAP) data interchange format.
We have used the following technology stack in Web services:
• WSDL provides description of service behavior and the interface contract.
• The HTTP protocol for network service. SOAP provides a platform independent protocol for sending messages across the wire.
• UDDI provides the means to discover the service both at design time and at run time.
• XML is the technology that underpins it all. Since XML is text based, it can be read by virtually any machine on any platform giving a high degree of interoperability. WSDL, UDDI, and SOAP are all XML based.
The implementation of this architecture consisted of specific focus on the following functional areas based for creation of a service centric approach.
• Authentication and Authorization. Security services provide a single point of entry for user authentication and system access authorization. User authentication service used multifactor authentication methods including passwords, RDS Secure ID tokens and X509 certificates which work with Microsoft single sign on architecture implemented with the help of Microsoft SharePoint Portal Server.
An LDAP based directory and RBAC defined system access privileges and rules control which public health application authenticated user are allowed to access. This is implemented using Microsoft Windows 2003 Active Directory.
Alerting services provided the necessary technical infrastructure to facilitate the distribution of notifications, warnings, reminders, and alerts to public health personnel and partner organizations. This is implemented using combination of MIR3 Enterprise server and custom developed components in Microsoft.NET technologies.
• PHIMS Inbound/Outbound Message Processing. The PHIMS Inbound/Outbound Message Processing area of the architecture is a collection of technologies and processes that enable the electronic exchange of information between the county public health application systems and external information systems. PHIMS Inbound/Outbound Message Processing implements standard and proprietary message formats for data exchange. Electronic trading partners include entities external to County of Los Angeles such as healthcare providers, state health department, laboratories, and public health partners. PHIMS Inbound/Outbound Message Processing can receive and send messages in various standards and legacy formats like HL7 v2.x, HL7 v3, HL7 CDA, CSV, ASCII Files etc. This is implemented using combination of custom developed Microsoft. NET applications and Microsoft BizTalk server.
• Functional Area (PAMS, CAMS and Shared Services). The Functional area of the architecture is a collection of program area modules, common area modules, and information routing technologies and processes used to manage conditions and events of public health interest. PAMs support the information and processing needs of a particular public health program such as communicable disease surveillance, environmental health, and bio-terrorism response management. CAM supports information and processing needs that transcend program areas such as laboratory information management, event detection, and controlled medical terminology services. PHIMS information routing technologies and processes include message parsing, transformation, and routing technologies and an integrated operational data store. The centralized operational data sore is developed based on HL7 V3 Reference Information Model (RIM) and implemented in Microsoft SQL Server 2000.
• Public Health Datamart and Public Health Dashboard. This is a collection of technologies and processes that facilitate analysis, visualization, and reporting of public health information. The data mart integrates data from multiple county public health, clinical, and administrative systems. The data are organized into facts and dimensions that allow multidimensional online analytical processing. The Public Health Datamart functions as a single source of truth for detail and aggregate public health data for use by a variety of business intelligence tools and applications. Business Intelligence services include both data analysis components and GIS components.
Data integration in healthcare has become a significant factor for any organization. In particular, County of Los Angeles goals are to have public health data be utilized for monitoring its population health dynamics and better plan for large scale health crises.
The decision to have data integration synchronized by use of HL7 healthcare standard messaging was in part to take into account the disparate applications and vendors already in existence in county.
The implementation of this integrated standards-based system in LAC provides a synchronized view of public health data and resources across all program areas (see Figure 2). High level implementation and testing strategies were put into place prior the development process. All processes were documented in depth for ongoing integration of PAMS and for future planning.
EVALUATION
The key components of the architecture include (see Figure 2) (1) Infrastructure & housekeeping services to provide authentication, directory and security services for the system and enable single sign-on. (2) A knowledge management module that manages translation and mapping of coded data from other systems to the Operational Data Store (ODS) in a standardized nomenclature. (3) Provision for single sign-on portal for authentication & entry into the system. It also incorporates an event alerting mechanism. (4) An electronic interface to systems that need to send data and receive data from the ODS, program area modules, and external data sources. (5) Analysis and Visualization services and data mart provide data analysis, reporting and GIS services through a dashboard. (6) Operational data store to save integrated data from functional area modules and external data sources.
The architecture provides the necessary infrastructure for a service oriented approach to development of functional area modules. Functional area modules support the business functions of public health. Some functional area modules are program specific (PAM), some are common to multiple program areas (CAM), and others are services invoked by PAMs and CAM. The services included in the architecture not only implement business functions but are essential infrastructure functions; security, alerting, messaging, terminology, and business intelligence. The development of functional area modules is streamlined due to the existence of these foun-dational features. The inbound and outbound messaging features enable functional modules integration and interoperability.
Web-enabled data management, tracking, decision support, and business intelligence systems, (including NPMS) have been developed for diverse agencies and departments within the Public Health system of Los Angeles County. All iterations from the design and planning phases to development, implementation and expansion were carefully evaluated with program users, administrative staff, and technology experts. The involvement of the user departments at all stages helped to develop systems that were easy and convenient to use.
The use of a model driven SOA has allowed the County of Los Angeles to take advantage of state-of-the-art information technologies while at the same time leveraging the investment made in its legacy application system. The use of industry standards positions the system to be interoperable with similar efforts conducted in other jurisdictions such as in neighboring Counties, the state of California, and the CDC.
It is proving to be a useful tool in assisting the County in coordinating the work of its multiple vendors, ensuring the coherent application of technologies to daily operations and preparedness activities, as well as, fostering collaboration between Los Angeles County Public Health and its partners.
In addition to design and development of a SOA architecture several other issues were brought up which helped in the implementation and planning of this architecture for public health in Los Angeles County. The vision by key county personnel expressing the necessity of data sharing and leveraging data as a department wide asset was clearly communicated. The CDC defined standards for use in enabling a public health information network has reached a level of maturity that could be utilized for the design elements of this architecture. The national recognition of the vulnerability of our public health system has motivated the United States Congress to allocate the funds necessary to underwrite the cost of development. Issues that continue to be part of the long term planning of this implementation include the inertia and tradition of autonomy enjoyed by program area leaders. The existence of silos in the program areas continue to yield challenges in navigation through the silo boundaries. The large scope of the implementation of this system and the presence of multiple vendors brings up coordination issues for business and technical needs and understandings for common grounds. The process of funding and resource limitations also becomes significant factors in the development process periodically.
conclusion
Towards the end of 2003, a project team was assembled to study the requirements of Public Health Information Management System (PHIMS) at Los Angeles County. The objective was to design a system architecture that met CDC’s Public Health Information Network (PHIN) standards. The design of the PHIMS architecture was completed in March 2004. The remainder of 2004 was spent on evaluations and analysis of the design with internal and external stakeholders. In addition the specifications were subjected to further refinement in conjunction with vendors. The vendors and County personnel were committed to assume accountability for implementing portions of the design, and developing plans for phased implementation of the architecture. By August 2005, core features of the architecture were implemented in a lab environment including prototype implementations of key functional components of the architecture. The entire countywide architecture is in the process of transitioning into production. There is ongoing emphasis in Los Angeles County Public Health to identify and prioritize PAMs which should be integrated into this architecture. The functional requirements of program area modules and the definition of an action plan for incorporating well-architected functional solutions into the technical infrastructure is ongoing.
It is expected that the Public Health Information Network System effort will expedite the consolidation of critical clinical and public health data across diverse individual IT systems (Verma et al., 2005). It will leverage existing investments in legacy systems and merge them with standards-based Web-enabled systems to provide a synchronized view of public health data and resources across all program areas. The LAC-ODS can be queried for a person-centric view of health-related data across all program areas. The visualization services provide a dashboard view and drill-down report capabilities for decision support and alignment of critical public health resources.
The PHIN compliant systems will specifically address the following (Health Alert Network, 2002; Los Angeles County Department of Health Services, 2004): (a) The development of a Web-based system architecture for Public Health programs and health districts that is capable of supporting electronic data exchange from public health partners using a HL7-based integration hub,
(b) the development of management tools and applications to assist public health response, and
(c) recovery activities while providing resources to support departmental integration. The PHIN/ NEDSS systems will leverage individual system components for the overall improvement of public health information technology infrastructure while contributing to the development of a common enterprise data warehouse that will unify public health and clinical data under a unique person identifier.
There are multiple systems in place that support communications for public health labs, the clinical community, and state, and local health departments. However, most of these systems operate in isolation. Numerous benefits will start accruing as parts of the system are built and integrated into the business processes of the local health services. The implementation of a unifying system will further improve access to laboratory data and response protocols, advanced capabilities for rapid notification of public health partners, response agencies, the media, and the general public. There will be an enhanced capability to train public health staff and a uniform data exchange standard for exchanging data between the public health partners. Real-time collection of data from heterogeneous healthcare systems, program area modules, consolidation, and cross-indexing of data, integrated directory infrastructure for public health personnel and identity management, integration of related healthcare, and patient data from heterogeneous systems into a common interface, provide access through a ubiquitous Web-based portal that will obviate the necessity of client-side implementations of application systems, provide a mechanism to disseminate critical and public-interest information to the community in general are additional benefits.
