Public Health Data Standards Consortium phdsc

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

2. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES PHDSC/HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES December 5-6, 2006, Washington DC

3. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES Goal The goal of the meeting is to build consensus among leaders in public health towards formalizing a vision for a standard representation of public health work processes for the electronic health information exchanges with clinical care, i.e. functional requirements specifications.

4. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES Meeting Objectives • Share experiences in building health information exchanges in panelists’ jurisdictions to date • Discuss national initiatives on the development of functional standards in health information exchanges • Discuss the functional specifications for health information exchanges on school health and on syndromic surveillance in New York City as prototypes of functional requirements specifications • Develop recommendations for the roadmap on developing functional requirements on health information exchanges between clinical care and public health

5. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES PANELISTS Dr. Oxiris Barbot, NYC Department of Health and Mental Hygiene, NY Dr. Neil Calman, Institute for Urban Family Health, NYC, NY Ms. Kathleen Cook, Lincoln-Lancaster County Health Deptment (City of Lincoln, County of Lancaster), NE Dr. Art Davisson, Denver Public Health, CO Dr. Peter Elkin, Mayo Clinic, Rochester, MN Dr. Shaun Grannis, Regenstrief Institute, IN Dr. Laurence Hanrahan, Wisconsin Department of Health and Family Services, WI Dr. Martin LaVenture, Minnesota Health Department, MN Dr. David Lawton, Nebraska Health and Human Services System, NE Dr. Farzad Mostashari, NYC Dept. of Health & Mental Hygiene, NYC Dr. Anna Orlova, Public Health Data Standards Consortium Dr. David Ross, Public Health Informatics Institute Dr. Tom Savel, Centers for Disease Control & Preventions (CDC) Dr. Walter Suarez, Public Health Data Standards Consortium

6. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES HRSA Project officers Ms. Jessica Townsend Dr. Michael Millman

7. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES DAY 1 December 5, 2006

8. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES AGENDA DAY 1 – Tuesday, December 5, 2006 (3.30-6.15pm) WELCOME AND INTRODUCTIONS Dr. Michael Millman, HRSA and Dr. Walter Suarez, PHDSC BUILDING PUBLIC HEALTH /CLINICAL HEALTH INFORMATION EXCHANGES: THE EXPERIENCE TO DATE: Efforts in Colorado, Indiana, Minnesota, Nebraska, New York City, and Wisconsin Moderator: Dr. Walter Suarez, PHDSC Participants: Invited Panelistsand Guests ROUNDTABLE DISCUSSION Moderator: Dr. Anna Orlova, PHDSC

9. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES SESSION 1: eHealth Data Exchanges between Public Health and Clinical Settings: Stories/Experience from Panelists Jurisdictions QUESTIONS FOR DISCUSSION 1. Community eHealth Data Exchanges: Purpose/Value Proposition for Public Health and Clinical Providers in the Community • Role of the Health Department in Being a Resource for Providers • Engaging Providers in the Public Health Mission of Protecting the Public from Health Threats and Improving the Effectiveness of Primary Care • Examples of Emerging eHealth Exchanges and How They are Bringing Together Public Health and Providers

10. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES SESSION 1: eHealth Data Exchanges between Public Health and Clinical Settings: Stories/Experience from Panelists Jurisdictions QUESTIONS FOR DISCUSSION 2. Key Implementation Activities, Choices, and Problems 3. Accomplishments and Lessons Learned 4. Building a Shared Vision - Suggestion for the Roadmap on Building eHealth Data Exchanges between Public Health and Clinical Setting

11. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES Day 1 Key Messages • Public Health Agencies efforts presented are targeted to specific programs, e.g., immunization. • Engaging primary care was challenging and not done broadly because to do it well requires significant workflow redesign and business cases does not hold up. Adoption of health IT and interoperability between systems are the key issues. • Functional requirements and other standards are needed to move things along. • Involve consumers as the key stakeholder for our efforts. Consumers should be involved to better understand their needs and improve our way of communication with them. • Public health activities discussed: immunization, registries. • Business cases are not only about monetary value. • Every solution should work with other solutions, this requires mind / process change. Solutions should be sustainable overtime.

12. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES DAY 2 December 6, 2006

13. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES AGENDA DAY 2 – Wednesday, December 6, 2006 (9.00am-12.00pm) THE CASE FOR ELECTRONIC HEALTH INFORMATION EXCHANGES IN PUBLIC HEALTH AND THE NEED FOR FUNCTIONAL STANDARDS Moderator: Lori Fourquet, Healthsign Systems Panelists Presentations: The Need for a Functional Requirements Standards in Public Health • Dr. David Ross, Public Health Informatics Institute Electronic Health Record System in Community Health Center in NYC • Dr. Neil Calman, Institute for Urban Family Health, NYC School Health Functional Requirements: NYC Case Study • Dr. Oxiris Barbot, NYC Department of Health & Mental Hygiene Syndromic Surveillance Functional Requirements: NYC Case Study • Dr. Farzad Mostashari, NYC Department of Health & Mental Hygiene A Functional Requirement Standard: National Efforts and User Role • Dr. Anna Orlova, PHDSC

14. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES AGENDA DAY 2 – Wednesday, December 6, 2006 (1.00-4.00pm) RESPONSES TO THE NYC FUNCTIONAL REQUIREMENTS: ROUNDTABLE DISCUSSION • Moderator: Dr. David Ross, Public Health Informatics Institute (PHII) ROADMAP FOR PUBLIC HEALTH FUNCTIONAL REQUIREMENTS STANDARDS: ROUNDTABLE DISCUSSION • Moderators: Dr. David Ross, PHII and Dr. Anna Orlova, PHDSC

15. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES SESSION 3: Responses to the NYC Functional Requirements: Roundtable Discussion DRAFT QUESTIONS FOR DISCUSSION • Does the NYC specifications framework adequately describe user needs in terms of system goal, actor, function, workflow and dataflow? • Does it include necessary elements needed to build the user requirements? What is missing? • Is it reusable for other public health domains/programs/jurisdictions? • What is the right name for this document – Functional Requirements Specification? Use Case Description? Functional Standard? Requirement Analysis Document (RAD)? Other?

16. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES SESSION 4: Roadmap for Public Health Functional Requirements Standards: Roundtable Discussion DRAFT QUESTIONS FOR DISCUSSION • Next steps (continued): • Facilitate a dialog between clinical and public health communities on the development of the interoperability specifications for clinical - public health data exchanges, e.g., participation in HITSP, CCHIT, IHE, etc. • Develop a Panel summary document on the meeting outcomes for  AHIC, NCVHS, ONC, RWJ and broader public health and clinical communities

17. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES SESSION 4: Roadmap for Public Health Functional Requirements Standards: Roundtable Discussion DRAFT QUESTIONS FOR DISCUSSION • Next steps (continued): • Work with PHDSC member organizations to organize education sessions on user functional requirements for information systems at their annual meetings, e.g., NACCHO, CDC PHIN, RWJ, Public Health Summit • Work with CDC and RWJ / NLM public health informatics program to include user functional specification development in the public health informatics training curriculum.

18. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES A Functional Requirement Standard: National Efforts and User Role Dr. Anna Orlova PHDSC

19. US Health Information Network - 2014 Source: Dr. Peter Elkin, Mayo Clinic, MN

20. DHHS’ Framework for Health Information Technology: Building a NHIN NHIN will be based on: • Electronic Health Record Systems (EHRS) that will enable • Regional Health Information Exchanges (RHIEs) organized via • Regional Health Information Organizations (RHIOs) Thompson TG and Brailer DJ. The Decade of Heath Information Technology to Deliver Consumer-centric and Information-rich Health Care. Framework for Strategic Action. US DHHS, July 21, 2004.

21. Source: Dr. Peter Elkin, Mayo Clinic, MN, 2006 RHIOs as NHIN Components

22. The Certification Commission for Healthcare Information Technology (CCHIT) Healthcare Information Technology Standards Panel (HITSP) American Health Information Community (Community) The Health Information Security and Privacy Collaboration (HISPC) Nationwide Health Information Network (NHIN) Architecture Projects PHDSC Involvement

23. NHIN Development Process In October 2005 DHHS Office of National Coordinator (ONC) awarded several NHIN contracts ($65M) as follows: • Standards Harmonization • EHR Certification • NHIN Architecture Prototypes • Health Information Security and Privacy URL: http://www.hhs.gov/healthit/ahic.html

24. US Health Care System Standardization: 2005-now Discussion Document Standards Harmonization Technical Committees Update Report to the Healthcare Information Technology Standards Panel HITSP includes 206 member organizations: 17 SDOs (8%) 161 Non-SDOs (79%) 18 Govt. bodies (8%) 10 Consumer groups (5%) Contract HHSP23320054103EC Arlington, VA September 20, 2006

25. HITSP Standards Categories – Feb 2006 • Data Standards (vocabularies and terminologies) • Information Content Standards (RIMs) • Information Exchange Standards • Identifiers Standards • Privacy and Security Standards • Functional Standards • Other HITSP definition

26. Standard Harmonization Process The Community identified 3 breakthrough areas for the NHIN development process in 2006: • Biosurveillance • Consumer Empowerment • Electronic Health Record * AHIC URL: www.hhs.gov/healthit/ahiccharter.pdf

27. Biosurveillance Use Case Transmit essential ambulatory care and emergency department visit, resource utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized Public Health Agencies with less than one day lag time. Source: HITSP Meeting, Arlington VA, September 20, 2006

28. AHIC Biosurveillance Use Case

29. AHIC-ONC BIO Consolidated Use Case Transaction Package Consumer/Patient Id X-ref Component Lab Report Message Component Radiology Msg Component Lab Terminology Component Encounter Msg Component Anonymize Base Std HL7V2.5 ADT^xxx Biosurveillance Patient-level data to Public Health Message-based Submission HITSP Biosurveillance – Patient-level and Resource Utilization Interoperability Specification Base Std HL7QBP^Q23 RSP^K23 Transaction Pseudonymize IHEXDS IHEPIXPDQ Message-based Scenario Terminology Standards Base Std ISO DTS/ 25237 Base Std ISO 15000ebRS 2.1/3.0 Base Std HL7 V2.5 Base Std HL7V2.5 ORU^R01 Base Std LOINC HCPCS HL7 V3 CPT HL7 V2.5 HIPAA SNOMED-CT CCC DICOM ICD 9/10 LOINC SNOMED-CT NCCLS UCUM UB-92 URL FIPS 5-2 HAVE

30. AHIC-ONC BIO Consolidated Use Case Transaction Package Consumer/Patient Id X-ref Component Lab Report Document Component Lab Terminology Component Anonymize Biosurveillance Patient-Level Data to Public Health Document-based Submission HITSP Biosurveillance – Patient-level and Resource Utilization Interoperability Specification Transaction Package Manage Sharing of Docs Document-based Scenario Transaction Notif of Doc Availability Base Std HL7QBP^Q23 RSP^K23 Transaction Pseudonymize IHEXDS IHEPIXPDQ IHE XDS-I IHE NAV IHE XDS-MS IHE XDS-LAB Terminology Standards Base Std HL7CDA r2 Base Std ISO DTS/ 25237 Base Std ISO 15000ebRS 2.1/3.0 Base Std HL7 V2.5 Base Std DICOM Base Std LOINC HCPCS HL7 V3 CPT HL7 V2.5 SNOMED-CT CCC HIPAA ICD 9/10 LOINC SNOMED-CT DICOM NCCLS UCUM UB-92 URL FIPS 5-2 HAVE

31. Biosurveillance Technical Committee Recommendations

32. System Development Process USER ROLE

33. System Development Process System developmentactivities • Requirements Elicitation • Design • Analysis • System design • Object design • Pilot testing • Implementation • Evaluation

34. Requirements Elicitation – User Role During Requirements Elicitation, the user and developerdefine the purpose of the system, i.e. identify a problem area and define a system that addresses the problem, and describe the system in terms of actors and use cases. Such a definition is called a requirements specification. The requirements specification is written in a natural language and supports communication between developers and client and users and serves as a contract between the client and the developers.

35. Requirements Elicitation Requirements Elicitationincludes the following activities: • Specifying problem/domain where system is needed • Identifying goals for the system • Identifying actors • Identifying functional requirements • Identifying use cases • Modeling user workflow and dataflow • Identify high level of system architecture • Identifying non-functional requirements • Stating project timeline and deliverables

36. Requirement Elicitation Functional requirements examples: • Support data collection (e.g., send data) • Store data • Manage data • Analyse data • Generate reports

37. Requirement Elicitation A nonfunctional requirement is a constraint on the operation of the system that is not related directly to a function of the system. Non-functional requirements have as much impact on the system as functional requirements.

38. Non-Functional Requirements Nonfunctional requirements falls into two categories – quality requirements and constraints or pseudo requirements. Quality Requirements • Usability • Reliability, dependability, robustness, safety • Performance (response time, throughput, availability, accuracy) • Supportability, adaptability, maintainability, portability

39. Non-Functional Requirements Constraints or Pseudo Requirements • Implementation requirements • Interface requirements • Operation requirements • System security requirements • Packaging requirements • Legal requirements

40. Work Products: Deliverables Requirement Analysis Document (RAD) is a product of the requirement elicitation process. RAD is a document (deliverable) that describes the system from the user’s point of view. RAD specifies a set of requirements for features that a system must have. RAD is used as a contractual document between the developer and the client.

41. System Requirements Specification Document: Outline • Introduction (Problem Overview) • 1.1 Purpose of the Proposed System • 1.2 Actors and Scope of the Proposed System • 1.3 Objectives and Success Criteria of the Project • 2. System Requirements • 2.1 Functional requirements • 2.3 Non-functional requirements • 3. System Models • 3.1 Use Case Description • 3.2 Use Case Models • 3.2.1 Use Case Diagram • 3.2.2 Work Flow and Data Flow Model • 3.3 High-Level System Architecture • 4. Project Development Timeline • 5. Testing / Evaluation Plan

42. Timeline and Deliverables Month 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 Requirement Elicitation Requirement Analysis Document (RAD) System Development System Development Specification Document Pilot Testing Pilot Testing Protocol & Report System Implementation System Documentation Prototype System Evaluation System Evaluation Protocol & Report System Operation System Documentation & Operational Manual

43. Developing a Vision for Functional Requirements Specification for Electronic Data Exchange between Clinical and Public Health Settings – NYC examples: • Examples of School Health • Syndromic Surveillance

44. Community Health Center (CHC) & Automated Student Health Record (ASHR) System Data Exchange Conduct pre-school physical examination at CHC Input exam data into CHC Electronic Health Record System (EHRS) that populates the 211S Form Primary Care Provider (PCP) & Community Health Center (CHC) Verify 211S Form Billy (Patient, Consumer, Student) Print 211S Form Update Personal Health Record (PHR) - My Chart Export 211S Form into ASHR Receive 211S Form from CHC EHRS Send 211S Form to a School Automated School Health Record (ASHR) Receive 211S Form from ASHR Review student data Billy’s Parent/Guardian File student data into a School Records System Communicate to a Guardian and PCP via ASHR and CHC EHRS regarding student health concern Italic font & represent future functions of electronic data exchange School Nurse & School Record System Fig 1. UML Use Case Diagram – Scenario 1: Healthy Child

45. Community Health Center (CHC) & Automated Student Health Record (ASHR) System Data Exchange Conduct pre-school physical examination at CHC Input exam data into CHC Electronic Health Record System (EHRS) that populates the 211S Form Verify 211S Form Verify the Request for Educational Services (RES) Form Primary Care Provider (PCP) & Community Health Center (CHC) Verify the Multi-Use Medication (MUM) Form Amy (Patient, Consumer, Student) Sign Consent Form Print 211S, RES and MUM Forms Update Personal Health Record (PHR) - My Chart Export 211S, RES and MUM Forms and Consentto ASHR Receive 211S, RES and MUM Formsand Consent from CHC EHRS Send 211S, RES and MUM Forms and Consent toa School Automated School Health Record (ASHR) Receive 211S, RES and MUM Forms and Consent from ASHR Amy’s Parent/Guardian Review student data Store 211S, RES and MUM Forms and Consentin Special Needs Database Administer medication to student Update student’s record on the use of medication in Special Needs Database School Nurse & School Record System & Special Needs Database Italic font & represent future functions of electronic data exchange Submit student record to CHC EHRS via ASHR Communicate to a Guardian and PCP via ASHR and CHC EHRS regarding student health

46. School Health: Current Work Flow and Data Flow Model: Scenario 1- Healthy Child Child with parent visits provider Provider completes 211S Parent deliver 211S to school School nurse enter 211S data into ASHR DOHMH maintains ASHR Reports Patient Record 211S Form 211S Form 211S Form 211S Form ASHR School DB EHR Reports CHC EHRS

47. School Health: Current Work Flow and Data Flow Model: Scenario 2- Child Has Asthma Consent Form Consent Form Parent completes Consent Form Child with parent visits provider Parent deliver Forms to school School nurse enter Forms data into ASHR DOHMH maintains ASHR Reports Provider completes 211S Form School Forms School Forms 211S Form 211S Form ASHR School DB Patient Record RES Form RES Form MUM Form MUM Form Reports EHR CHC EHRS

48. Community Health Centers (CHC) New York City Schools New York City Department of Health & Mental Hygiene EHR School Forms CHC-I EHRS School-I System School Forms EHR 211S Form Consent Form School Forms CHC-II EHRS RES Form MUM Form School-II System Automated Student Health Record (ASHR) System EHR School Forms CHC-N EHRS School-N System

49. PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES SESSION 3: Responses to the NYC Functional Requirements: Roundtable Discussion DRAFT QUESTIONS FOR DISCUSSION • Does the NYC specifications framework adequately describe user needs in terms of system goal, actor, function, workflow and dataflow? • Does it include necessary elements needed to build the user requirements? What is missing? • Is it reusable for other public health domains/programs/jurisdictions? • What is the right name for this document – Functional Requirements Specification? Use Case Description? Functional Standard? Requirement Analysis Document (RAD)? Other?

50. Functional Requirements Specifications for Electronic Data Exchange between Clinical Care and Public Health WHERE TO START?