1 / 41

Towards Common Work Processes: Business Process Analysis for Public Health

This article discusses the need for standardized work processes in public health and the importance of business process analysis in creating functional requirements for information systems. It also highlights the projects and initiatives of the Public Health Data Standards Consortium in developing functional standards for various public health areas.

bruno
Download Presentation

Towards Common Work Processes: Business Process Analysis for Public Health

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

E N D

Presentation Transcript

  1. Public Health Data Standards Consortiumhttp://www.phdsc.org

  2. Towards Common Work Processes: Business Process Analysis and Functional Requirements Analysis for Public HealthAnna Orlova, PhDPublic Health Data Standards Consortiumaorlova@jhsph.edu PUBLIC HEALTH DATA STANDARDS CONSORTIUM~ 2009 BUSINESS MEETING OF MEMBERS ~ November 12-13, 2009, Hyattsville, MD

  3. Where We Now

  4. State Health Department: Organizational Chart

  5. Use of IT in Public Health: Where We Now All public health activities are supported by customized information systems (databases, registries) developed to address the programmatic needs.

  6. Our information systems do support our programmatic needsOur information systems cannot exchange data between programs within and across public health agencies and with clinical information systems HIT Standards in Public Health: Where We Now AND…… BUT……

  7. Why Standards - National Context Towards a Nationwide Health Information Network Where Should We Be in 2014

  8. US Nationwide Health Information Network (NHIN) in 2014 Source: Dr. Peter Elkin, 2006

  9. Source: Dr. Peter Elkin, 2006 RHIEs as NHIN Components

  10. Vision: PH Surveillance under NHIN Percent of Children Tested for Lead with BLL>10 µg/dL in the USA Source: Eileen Koski. Quest Diagnostics. PHIN-2004, May, Atlanta GA

  11. Standardizing Health Information Exchanges

  12. From Business Processes to Functional Requirements to Standardized IT Solutions

  13. Describing Business Processes PHII Common Grounds Project “We hope to develop a shared understanding of public health work and identify areas of commonality among public health agencies," said Dave Ross, Sc.D., director of the Common Ground National Program Office at the Public Health Informatics Institute. "The Common Ground program offers public health agencies the opportunity to collaboratively develop requirements for more effective information systems and better data exchange.” Source: Public Health Informatics Institute (PHII). URL:http://www.phii.org/programs/CommonGround.asp

  14. Describing Functional Requirements

  15. Requirements Elicitation • The purpose of the requirements elicitation is to specify • the information system features from user’s • perspectives in a structured Functional Requirements Analysis Document (Functional Standard). • FRAD Features: • Information System Goals (Tasks) • Actors • Functions (Actions) • Data Sources • Workflow and Dataflow • High Level Architecture

  16. Functional Standard Functional Standard describes work processes that support data exchange between users (e.g., clinicians and public health practitioners) in a format of functional requirements specification for electronic communication between settings (e.g., clinical and public health settings).

  17. Functional Standard Functional standard is a vehicle to assure that the work processes of stakeholders (e.g., clinicians and public health practitioners) related to the electronic data exchange are well understood and agreed upon by stakeholders themselves and then communicated clearly to the developers as functional requirements for the information system.

  18. Defining Requirements “Defining system requirements is the most important step in developing or acquiring any information system. A well-conceived and planned health information system can help organizations understand the need to adjust tasks or processes to be more effective or proactive in protecting community health….” Source: Public Health Informatics Institute (PHII). URL:http://www.phii.org/subjectareas/requirementsdevelopment.asp

  19. PHDSC FRAD Projects* • Early Hearing Detection and Intervention Content Profile, 2009-10 • Standards for Public Health Data Exchanges: Working with Vendors (Newborn Screening, Diabetes, Quality), 2009 • Standards for Public Health Data Exchanges: Functional Requirements Standard for Diabetes Care Management and Surveillance, 2008 • Towards a Functional Standards on Electronic Data Exchange between Clinical Care and Public Health, 2007 • Developing a Vision for Functional requirements Specification for Electronic Data Exchange between Clinical and Public Health Settings: Examples of School Health and Syndromic Surveillance in New York City, 2006 *Supported by Health Resources and Services Administration, 2005-2009 URL:http://www.phdsc.org/health_info/com_nhin_activities.asp

  20. From Business Processes to Functional Requirements to Standardized IT Solutions Using SOA(Service-Oriented Architecture)

  21. Example of Environmental Public Health Tracking

  22. Examples of Tasks to be Addressed by the Environmental Health Tracking Network Public Health Questions • What are the impacts of pesticide exposure on children’s health? • Are changes in the environment related to dramatic increase in asthma? • Are there increases in Systemic Lupus Erythmetosis (SLE) and multiple sclerosis (MS) in communities with hazardous waste sites? Public Health Actions – Business Processes • Detect new adverse health events associated with environmental exposures. • Track health, disease, and risks to target interventions to those populations most affected by environmental hazards and exposures. • Detect unusual occurrences, trends, or clusters of specific health events associated with environmental exposures. • Monitor and assess the effects of policies and the efficacy of interventions and established prevention strategies. • Raise awareness about environmental health issues among consumers, policy makers, health practitioners, industry, the public, and the media. Source: Dr. Nabil Issa, CDC/NCEH

  23. Environmental Public Health Tracking Network N Exposure Hazards Public Health Actions State and National Data Collection Systems • Track health, disease, and risk trends • Establish program priorities • Develop, implement, and evaluate public health policies and program strategies • Develop rapid-response mechanisms to investigate outbreaks and clusters • Develop guidelines/standards • Generate hypotheses and initiate applied research • Environmental Hazards Tracking • Population Census • Environmental Exposure Tracking • Health Outcomes Tracking Integrated Environmental Health Tracking, Analysis, Evaluation And Dissemination USER VIEW Source: Dr. Nabil Issa, CDC/NCEH

  24. Track health, disease, and exposure risk/trends • Detect & evaluate risk of exposure to env. hazards • Develop & evaluate public health & environmental stewardship policies & programs • Develop rapid-response mechanisms to investigate outbreaks and clusters • Develop prevention guidelines/standards • Generate hypotheses and initiate applied research Environmental Stewardship & Public Health Actions Exposure Detection & Risk Analysis GIS/Spatial Epidemiology Risk Analysis Data Mining & Knowledge Discovery Statistical Models Population Environmental Hazard Natural Health Outcomes Exposure Accidental Integrated Environmental Health Indicators Data Warehouse Intentional Hazardous Material Profile Exposure Profile Biomonitoring Population Demography Ecological Indicators Disease Indicators Data Integration, Transformation & Geocoding Metadata Data Standardization Data Linking/Integration Data Quality Assurance Geocoding • Hazards • Tracking* • Hazardous Substances-Emergency Event Surveillance • Toxic Release Inventory • Exposure • Tracking* • Human Exposure to Environmental Chemicals • Toxic Exposure Surveillance • Ecological Tracking* • Marine Life • Animals • Plants • Population Demographics* • Census Data • Disease Tracking* • Hospital Discharge • Birth Defects • BRFSS • Cancer Registries • Health Surveys • Vital Statistics Environmental Hazards, Ecology and Disease Data Collection Systems (*) Based on risk assessment and national priorities System Architecture for Environmental Health Risk Detection, Assessment & Management Informatician View Source: Dr. Nabil Issa, CDC/NCEH

  25. Environmental Public Health Tracking Information Exchanges Developer View System System System System System System System System Source: HITSP, 2009

  26. State Health Department: Organizational Chart

  27. Business “Top Down” User Driven (Requirements Driven) Business Processes Use Cases

  28. Business “Top Down” User Driven (Requirements Driven) Business Processes Use Case Use Case Use Case Towards a Public Health Domain at IHE

  29. Business “Top Down” User Driven (Requirements Driven) Business Processes Use Case Use Case Use Case Functional Requirements/ Capabilities Functional Requirements/ Capabilities Functional Requirements/ Capabilities Towards a Public Health Domain at IHE

  30. Business “Top Down” User Driven (Requirements Driven) Business Processes Use Case Use Case Use Case Functional Requirements/ Capabilities Functional Requirements/ Capabilities Functional Requirements/ Capabilities Working with Developers at the Integrating the Healthcare Enterprise (IHE) Towards a Public Health Domain at IHE

  31. Integration Profile PIX, PDQ, RFD, XDS Actor Actor Actor IHE Technical Frameworks “Bottom-Up” Health IT Solution Driven Content Profile Content Profile Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Actor Actor Actor Towards a Public Health Domain at IHE

  32. Business “Top Down” User Driven (Requirements Driven) Business Processes Use Case Use Case Use Case Functional Requirements/ Capabilities Functional Requirements/ Capabilities Functional Requirements/ Capabilities Integration Profile PIX, PDQ, RFD, XDS Actor Actor Actor IHE Technical Frameworks “Bottom-Up” Health IT Solution Driven Content Profile Content Profile Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Actor Actor Actor Towards a Public Health Domain at IHE

  33. Service-Oriented Architecture (SOA) Service Layers Task Service Layer Entity Service Layer Utility Service Layer

  34. Example of Service Layers / Integration Profile Mapping Task Services GetPatientLHR Entity Services Identity Document Utility Services / IHE Integration Profiles PIX Mgr PDQ Mgr Registry Repository Audit

  35. Business “Top Down” User Driven (Requirements Driven) Business Processes Use Case Use Case Use Case Functional Requirements/ Capabilities Functional Requirements/ Capabilities Functional Requirements/ Capabilities Integration Profile PIX, PDQ, RFD, XDS Actor Actor Actor IHE Technical Frameworks “Bottom-Up” Health IT Solution Driven Content Profile Content Profile Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Actor Actor Actor Towards a Public Health Domain at IHE

  36. IHE & SOA White Paper Business “Top Down” User Driven (Requirements Driven) Business Processes Use Case Use Case Use Case Functional Requirements/ Capabilities Functional Requirements/ Capabilities Functional Requirements/ Capabilities Task Service Layer Entity Service Layer Integration Profile Utility Service Layer PIX, PDQ, RFD, XDS Actor Actor Actor IHE Technical Frameworks “Bottom-Up” Health IT Solution Driven Content Profile Content Profile Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Transaction Actor Actor Actor Towards a Public Health Domain at IHE

  37. Value of SOA SOA links business and functional requirements to standardized interoperable IT solutions For Users (Public Health Professionals and Clinicians) Ability to navigate and select appropriate IT standards/ products for a service that is understandable for a non-technical audience, ie, identity service, document service, etc. Ability to relate user requirements to IHE technical solutions (capabilities) Ability to see commonalities for technical solutions across business processes

  38. Value of SOA SOA links business and functional requirements to standardized interoperable IT solutions For Developers Help users and their IT vendors to navigate through interoperability standards Help IT vendors to correctly use interoperability products in their applications Develop new IT products for services requested by users, ie, identity service, document service, etc.

  39. Value of SOA SOA links business and functional requirements to standardized interoperable IT solutions So, together we can built interoperable, standards-based IT products that will adhere to user needs to assure “meaningful use” of Health IT

  40. Resources: A Service-Oriented Architecture (SOA) View of IHE Profiles – White Paper at the Integrating the Healthcare Enterprise (IHE). (URL: https://sites.google.com/site/projecthrsaphdsc/objective-2

  41. Questions?

More Related