Public Health Data Standards Consortium http:www'phdsc'org

1
Public Health Data Standards Consortium
http//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 Panelists and 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

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
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
Biosurveillance Patient-level data to Public
Health Message-based Submission
HITSP
Biosurveillance Patient-level and Resource
Utilization Interoperability Specification
Base Std HL7QBPQ23 RSPK23
Transaction Pseudonymize
IHEXDS
IHEPIXPDQ
Message-based Scenario
Base Std ISO DTS/ 25237
Terminology Standards
Base Std HL7 V2.5
Base Std ISO 15000ebRS 2.1/3.0
Base Std LOINC
Base Std HL7V2.5 ORUR01
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
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 HL7QBPQ23 RSPK23
Transaction Pseudonymize
IHEXDS
IHEPIXPDQ
IHE XDS-I
IHE NAV
IHE XDS-LAB
IHE XDS-MS
Terminology Standards
Base Std HL7CDA r2
Base Std ISO DTS/ 25237
Base Std HL7 V2.5
Base Std ISO 15000ebRS 2.1/3.0
Base Std LOINC
Base Std DICOM
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 development activities
• Requirements Elicitation
• Design
• Analysis
• System design
• Object design
• Pilot testing
• Implementation
• Evaluation

34
Requirements Elicitation User Role

• During Requirements Elicitation, the user and
  developer define 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 Elicitation includes 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 users 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
Billys 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 Consent to ASHR
Receive 211S, RES and MUM Forms and Consent from
CHC EHRS
Send 211S, RES and MUM Forms and Consent to a
School
Automated School Health Record (ASHR)
Receive 211S, RES and MUM Forms and Consent from
ASHR
Amys Parent/Guardian
Review student data
Store 211S, RES and MUM Forms and Consent in
Special Needs Database
Administer medication to student
Update students 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
ASHR
211S Form
211S Form
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
School Forms
211S Form
Consent Form
CHC-II EHRS
School-II System
RES Form
MUM Form
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?

51
Knowledge Management in Public Health

• WHAT IS PUBLIC HEALTH?

52
Public Health Organization

• Public health nowadays is
• Agency
• Healthcare provider
• Laboratory
• Purchaser
• Payor
• Pharmacy
• Research

53
Public Health Organization

• Public health nowadays is
• Agency
• Healthcare provider
• Laboratory
• Purchaser
• Payor
• Pharmacy
• Research

Publicly-delivered Healthcare Care
54
Public Health Organization

• Public health nowadays is
• Agency Assessment, Policy Development and
  Assurance
• There are local, state, and federal public health
  agencies.
• Their activities are organized by services and/or
  disease-specific programs as indicated in the
  tables that follow.

55
Public Health Information Systems

• Local and State Public Health Systems, e.g.,
  immunization registry, blood lead registry,
  asthma registry, trauma registry, communicable
  diseases registry, syndromic surveillance, etc.
• CDC National Electronic Disease Surveillance
  System (NEDSS)
• CDC Environmental Public Health Tracking Network
  (EPHTN)
• CDC Public Health Information Network (PHIN)

56

• Responsibilities of State Health Agencies 2001

State Health Agencies Functions
SourceBeitsch LM et al. Structure and functions
of state public health agencies. APHA.
200696(1)167-72
57

• Responsibilities of Local Public Health Agencies

Local Health Agencies Functions
Source Scutchfield, F.D., Keck, C.W.
Principles of public health practice, 2nd ed.
2003. Thomson/Delmar Learning Clifton Park, NY.
58

• All public health activities are supported by
  customized information systems (databases,
  registries) developed to address the programmatic
  needs.

59
Number of Public Health Programs/Systems

• On average, there are
• 23 programs in the Local Health Departments (HDs)
• 19 programs in the State Health Departments
• There are 3000 local HDs and 50 State HDs in the
  US
• 23 x 3000 (Local HD) 69000 local
  programs/systems
• 19 x 50 (State HD) 950 state programs/systems
• So roughly, there are over 70 thousands public
  health information systems -- all of them are
  customized, siloed systems.

60
Clinical Public Health Data Exchanges Local
Health Agencies
Health Education/Risk Reduction
Provider 1
Communicable Diseases
Provider 2
Immunization
EPSDT
Provider 3
Injury Control
School Health
Provider 4
Chronic Care
Biosurveilance, BT, Preparedness
WIC
Provider X
Occupational Safety and Health
61
Clinical Public Health Data Exchanges State
Health Agencies
Genetic Disorder
Vital Statistics
Communicable Diseases
Provider 1
Immunization
Lead and Environmental Epidemiology
Provider 2
Injury Control
Provider 3
School Health
Provider 4
Chronic Care
Biosurveilance, BT, Preparedness
WIC
Public Health Laboratory
Provider X
HEDIS
Cancer
Source Beitsch et.al Structure and Function of
State Public Health Care Agencies / AJPH,
January, 2006.
62
Clinical-Public Health Data Exchanges Local /
State / Federal Health Agencies
Genetic Disorder
Vital Statistics
Health Education/Risk Reduction
CDC
Communicable Diseases
Provider 1
HRSA
Communicable Diseases
Immunization
AHRQ
Lead Registry
Provider 2
Immunization
EPSDT
Injury Control
Provider 3
Injury Control
School Health
School Health
Chronic Care
Provider 4
Biosurveilance, BT, Preparedness
Chronic Care
Biosurveilance, BT, Preparedness
WIC
Public Health Laboratory
WIC
Provider X
Occupational Safety and Health
HEDIS
Cancer
Source Beitsch et.al AJPH, January, 2006.
63
Paper-based Health Data Exchanges
Genetic Disorders
Communicable Diseases
Provider 1
On average 49 of cases got reported (CDC, 2006).
Immunization
Provider 2
Vital Records
Provider 3
Injury Control
Provider 4
School Health
Chronic Care
Biosurveilance, BT, Preparedness
Provider X
HEDIS
64
Reasons for Underreporting to Public Health
Agency

• Lack of Knowledge of the Reporting Requirement
• Unaware of responsibility to report
• Assume that someone else (e.g., a laboratory)
  would report
• Unaware of which disease must be reported
• Unaware of how and whom to report
• Negative Attitude Towards Reporting
• Time consuming
• Too much hassle (e.g., unwieldy report form or
  procedure)
• Lack of incentive
• Lack of feedback
• Distrust of government
• Misconceptions that Result from Lack of Knowledge
  or Negative Attitude
• Compromises patient-physician relationship
• Concern that report may result in a breach of
  confidentiality
• Disagreement with need to report
• Judgment that the disease is not that serious
• Belief that no effective public health measures
  exist
• Perception that health department does not act on
  the report

Source Centers for Disease Control and
Prevention. Lesson Five Public Health
Surveillance. Principles of Epidemiology in
Public Health Practice. 3rd Ed. 336-409.
Available at http//www.cdc.gov/training/products
/ss1000/ss1000-ol.pdf.
65
EHR-PH System Prototype for Interoperability in
21st Century Health Care System
Public Health Surveillance
Clinical Care
Hospital of Birth
State Health Department
ADT- Birth Record
Newborn Screening Registry
HL7 2.4
HL7 3.0
Newborn Screening Test
HL7 3.0
EHR-PH Info Exchange
Hearing Screening Registry
HL7 3.0
HL7 3.0
Hearing Screening Test
HL7 2.4
Immunization Registry
HL7 2.4
HL7 3.0
Immunization Administration
Communicable Disease Registry
HL7 2.4
J2EE
HTB
External Laboratory
J2EE
Wrtwertghghgghhghg Wrtwrtghghghghgh Wtrwtrghgg Wrt
wrtghghgh Aadkalfjkaldkfjalkdjflajhjkhjkhjkhk flkd
jghghghghghghghgh
Healthcare Transaction Viewer
Wrtwertghghgghhghg Wrtwrtghghghghgh Wtrwtrghgg Wrt
wrtghghgh Aadkalfjkaldkfjalkdjflajkflkdjghghghghgh
ghghg fhjfghjfh
HTB Health Transaction Base
Source Orlova, et al. HIMSS 2005,Dallas TX,
February 13-17, 2005 and AMIA, Washington DC,
November, 2005
66
EHR-PH System Prototype for Interoperability in
21st Century Health Care System
EHR-PH System Prototype for Interoperability in
21st Century Health Care System
Public Health Surveillance
Clinical Care

• Our Prototype
• Shows how interoperability between healthcare
  systems can be achieved with a standards-based
  infrastructure
• Is built upon existing systems in clinical care
  and public health programs
• Enables electronic data reporting from a clinical
  setting to multiple public health systems
• Enables translation of customized standards into
  HL7 3.0 messaging standard
• Links clinical and public health systems to
  provide a continues view of the patient record
  across the systems involved

67
Towards EHR-PH Data Exchange Clinical Care
Public Health
Genetic Disorders
Communicable Diseases
Provider 1
Immunization
Provider 2
Vital Records
Provider 3
Injury Control
Provider 4
School Health
Chronic Care
Biosurveillance, BT, Preparedness, Syndromic
Surveillance
Provider X
HEDIS
68
Towards EHR-PH Data Exchange Clinical Care
Public Health
EHR
Genetic Disorders
EHR
CDA (Clinical Data Architecture)
Communicable Diseases
Provider 1
Immunization
Provider 2
IHE (Integrated Healthcare Enterprise) LAB
Vital Records
Provider 3
Injury Control
Provider 4
School Health
Chronic Care
Biosurveilance, BT, Preparedness, Syndromic
Surveillance
Provider X
HEDIS
69
HITSP Registration Medication History Document
ASTM/HL7 CCD Based Document
CDA Rel2
CDA Level 1 Header HL7 CCD/CRS Implementation
Guide
CDA Level 2 Human Rendering (CCD Loinc Section
Codes)
X12 X271

• CDA Level 3 Coded Entries
• (CCD/MS Entries)
• Personal Information
• Healthcare Provider
• Insurance Provider
• Allergies and Drug Sensitivity
• Condition
• Medications
• Pregnancy
• Advance Directives

NCPDP Script
ASTM/CCR
CCD - Clinical Care Document, CDA Rel2 Clinical
Data Architecture, Release 2, CCR Continuity
Care Record
70
EHR-PH Data Exchange Clinical Public Health
Systems
EHR
Genetic Disorders
Communicable Diseases
Provider 1
CDA2
Immunization
Provider 2
Vital Records
X12
Provider 3
Injury Control
Provider 4
School Health
NCPDP
Chronic Care
Biosurveilance, BT, Preparedness, Syndromic
Surveillance
Provider X
IHE LAB
HEDIS
71

• FORMS

72
EHR-PH Data Exchange Clinical Public Health
Systems
EHR
Forms
Genetic Disorders
CDA2
Communicable Diseases
Provider 1
IHE LAB
Immunization
Provider 2
Vital Records
Provider 3
Injury Control
NCPDP
Provider 4
School Health
SH
Chronic Care
X12
Biosurveilance, BT, Preparedness, Syndromic
Surveillance
Provider X
BT
HEDIS
73
EHR-PH Data Exchange Clinical Public Health
Systems
EHR
Forms
Genetic Disorders
NBS
CDA2
Communicable Diseases
TB, STD.
Provider 1
IHE LAB
Immunization
IR
Provider 2
Vital Records
VR
Provider 3
Injury Control
NCPDP
ECIC
Provider 4
School Health
SH
Chronic Care
CVD, Asthma Diabetes
X12
Biosurveilance, BT, Preparedness, Syndromic
Surveillance
Provider X
BT
HEDIS
HEDIS
74

• Functional Requirements Specifications for
  Electronic Data Exchange between Clinical Care
  and Public Health
• WORKING WITH VENDOR COMMUNITY

75

• Providers and Software Developers
• Working Together to Deliver
• Interoperable Health Information Systems
• in the Enterprise
• and Across Care Settings

76
Integrating the Healthcare Enterprise (IHE)
Overview

• Presented by Dan Russler, M.D., IHE PCC Co-chair
• IHE Workshop June 19, 2006

77
Why IHE?

• 1970sMainframe Era--100,000 per interface
• 1990sHL7 2.x--10,000 per interface
• 2000sIHE Implementation Profiles
• Cheaper than a new phone line!
• How? IHE Eliminates Options Found in Published
  Standards

78
Who is IHE?

• IHE is a joint initiative among
• American College of Cardiology (ACC)
• Radiological Society of North America (RSNA)
• Healthcare Information Management Systems Society
  (HIMSS)
• GMSIH, HPRIM, JAHIS (laboratory)
• American Society of Ophthalmology
• American College of Physicians (ACP)
• American College of Clinical Engineering (ACCE)
• And many more.
• Began in 1997 in Radiology (RSNA) and IT (HIMSS)
• International effort IHE- Europe and IHE-Asia
• Additional sponsors for Cardiology including ASE,
  ESC, ASNC, SCAI, HRS and more

79
IHE 2006 Nine Active Domains
Over 100 vendors involved world-wide, 5 Technical
Frameworks 37 Integration Profiles, Testing at
Connectathons Demonstrations at major conferences
world-wide 15 Active national chapters on 4
continents
80
IHE Standards-Based Integration Solutions

Prof
essional
Societies Sponsorship


Healthcare Providers Software Developers

Healthcare IT Standards

General IT Standards




HL7, DICOM, etc.
Internet, ISO, etc.
IHE

Process

Interoperable Healthcare IT
Solution Specifications

Interoperable Healthcare IT

IHE Integration Profile
Solution Specifications

Interoperable Healthcare IT

IHE Integration Profi
le
Solution Specifications

Interoperable Healthcare IT

IHE Integration Profile
Solution Specifications


IHE Integration Profile
81
IHE in 2006 18 Month Development Cycles

• First Cycle
• Planning Committee Proposals November, 2005
• Technical Committee Drafts June, 2006
• Public Comment Due July 2006
• Trial Implementation Version August 2006
• Mesa Tool Test Results Due December 2006
• IHE Connectathon January 2007
• HIMSS Demo February 2007
• Participant Comments Due March 2007
• Final Implementation Version June 2007

82
IHE Technical Frameworks
Detailed standards implementation guides
83
HIMSS IHE Interoperability ShowcaseFebruary 2006
Participants
Leadership Level Blue Ware Cerner GE Healthcare
IDX IBM Initiate Systems InterSystems MiSys
Healthcare Quovadx Siemens
84
IHE Connectathon, January 2006

• 300 participants, 120 systems
• 60 systems developers
• Four Domains Cardiology, IT Infrastructure,
  Patient Care Coordination, Radiology
• 2800 monitored test cases

85

• Results
• Over 3000 attendees visited the HIMSS RHIO
  Showcase
• 37 vendors demonstrated 48 systems
• 700 attendees created and tracked their own
  health record
• 63 educational sessions were presented
• 5 International delegations
• 3 VIP tours
• 16 clinical scenarios were demonstrated

86
IHE Integration Profiles for Health Info
NetsWhat is available and has been added in 2005
and is for 2006
Clinical and PHRContent
Patient Id Mgt
Security
Health Data Exchange
Other
87
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 HL7QBPQ23 RSPK23
Transaction Pseudonymize
IHEXDS
IHEPIXPDQ
IHE XDS-I
IHE NAV
IHE XDS-LAB
IHE XDS-MS
Terminology Standards
Base Std HL7CDA r2
Base Std ISO DTS/ 25237
Base Std HL7 V2.5
Base Std ISO 15000ebRS 2.1/3.0
Base Std LOINC
Base Std DICOM
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
88

• Providers and Software Developers
• Working Together to Deliver
• Interoperable Health Information Systems
• in the Enterprise
• and Across Care Settings

89
PHDSC was Invited to Sponsor Public Health
Domain at IHE

• Public Health Efforts at IHE
• White Paper on Public Health Case Management
  Profile due July 2007
• Can be PHDSC-sponsored
• Profile Proposal on Aggregate Data Retrieval from
  Document-Sharing Resource
• Siemens- and Oracle-sponsored
• Profile Proposal on Public Health Reporting
• IBM-sponsored

90
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?

91
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES

• SESSION 4
• Roadmap for Public Health Functional Requirements
  Standards Roundtable Discussion
• DRAFT QUESTIONS FOR DISCUSSION
• Our recommendations
• Accept the specification as a working document
• Next steps
• Work with public health (States, HRSA, CDC),
  clinical (AAFP, AAP, AMA) communities and vendors
  (HIMSSs IHE) to finalize the representation of
  the public health functional requirements for
  interoperable clinical-public health systems
• Expand the proposed specifications by describing
  other domains (use cases) of clinical public
  health data exchanges

92
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

93
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.