Transcript Slide 1

Public Health Data Standards Consortium
http://www.phdsc.org
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES
PHDSC/HRSA EXPERT PANEL
IN ELECTRONIC DATA EXCHANGES
December 5-6, 2006,
Washington DC
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.
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
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
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES
HRSA Project officers
Ms. Jessica Townsend
Dr. Michael Millman
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES
DAY 1
December 5, 2006
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
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
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
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES
Day 1 Key Messages
1.
2.
3.
4.
5.
6.
7.
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.
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES
DAY 2
December 6, 2006
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
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
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?
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
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.
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA
EXCHANGES
A Functional Requirement Standard:
National Efforts and User Role
Dr. Anna Orlova
PHDSC
US Health Information Network - 2014
Source: Dr. Peter Elkin, Mayo Clinic, MN
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.
Source: Dr. Peter Elkin, Mayo Clinic, MN, 2006
RHIOs as NHIN Components
PHDSC Involvement
The Certification
Commission for
Healthcare
Information
Technology
(CCHIT)
The Health
Information
Security and
Privacy
Collaboration
(HISPC)
Healthcare
Information
Technology
Standards Panel
(HITSP)
American Health
Information
Community
(Community)
Nationwide
Health
Information
Network (NHIN)
Architecture
Projects
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
US Health Care System Standardization: 2005-now
Discussion Document
Standards Harmonization Technical
Committees Update
Report to the Healthcare Information Technology
Standards Panel
Contract HHSP23320054103EC
HITSP includes 206
member organizations:
17 SDOs (8%)
161 Non-SDOs (79%)
18 Govt. bodies (8%)
10 Consumer groups (5%)
Arlington, VA
September 20, 2006
HITSP Standards Categories – Feb 2006
1.
2.
3.
4.
5.
6.
7.
Data Standards (vocabularies and
terminologies)
Information Content Standards (RIMs)
Information Exchange Standards
Identifiers Standards
Privacy and Security Standards
Functional Standards
Other
HITSP definition
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
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
AHIC Biosurveillance Use Case
Event Detection
Neighboring
Jurisdictions
Hospital
State Public Health
Surveillance System
4- Report/retrieve of symptoms,diagnosis
& medication prescription data from EHRS
Ambulatory
Care
9 – Order
test
13 – Report on the positive case
electronically & by phone
4 – Data mining
of EMR notes
7 – Notify on
increased number
of cases &
recommend to
order specific tests
11 – Report
test result
electronically
& by phone
Local
Public Health
Surveillance
System
DHHS
Media
Laboratory
Pharmacy
Response
Team
P
U
B
L
I
C
Biosurveillance
AHIC-ONC BIO Consolidated Use Case
Patient-level data to Public Health
Message-based Submission
HITSP
Biosurveillance – Patient-level and Resource Utilization Interoperability Specification
Transaction Package
Consumer/Patient Id X-ref
Transaction
Pseudonymize
Message-based
Scenario
Component
Encounter Msg
Lab Report Message
Radiology Msg
Terminology
Standards
HCPCS HL7 V3
CPT HL7 V2.5
CCC SNOMED-CT
ICD 9/10 LOINC
NCCLS
UCUM
UB-92
URL
FIPS 5-2
HAVE
Base
Std
HL7V2.5
ADT^xxx
Base
Std
HL7V2.5
ORU^R01
IHE
XDS
IHE
PIX
PDQ
Component
Component
Component
Base
Std
HL7
QBP^Q23
RSP^K23
Anonymize
Component
Lab Terminology
Base
Std
LOINC
SNOMEDCT
Base
Std
ISO
DTS/
25237
HIPAA
DICOM
Base
Std
ISO 15000
ebRS 2.1/3.0
Base
Std
HL7 V2.5
Biosurveillance
AHIC-ONC BIO Consolidated Use Case
Patient-Level Data to Public Health
Document-based Submission
HITSP
Biosurveillance – Patient-level and Resource Utilization Interoperability Specification
Transaction Package
Consumer/Patient Id X-ref
Transaction Package
Manage Sharing of
Docs
Document-based
Scenario
Transaction
Notif of Doc Availability
IHE
XDS-I
Base
Std
HL7
QBP^Q23
RSP^K23
Transaction
Pseudonymize
IHE
NAV
IHE
XDS
IHE
PIX
PDQ
Component
Lab Report Document
Component
Anonymize
Component
Lab Terminology
Base
Std
DICOM
Base
Std
LOINC
SNOMEDCT
IHE
XDS-MS
Base
Std
HL7
CDA r2
IHE
XDS-LAB
Terminology
Standards
HCPCS HL7 V3
CPT HL7 V2.5
CCC SNOMED-CT
ICD 9/10 LOINC
NCCLS
UCUM
UB-92
URL
FIPS 5-2
HAVE
Base
Std
ISO
DTS/
25237
HIPAA
DICOM
Base
Std
ISO 15000
ebRS 2.1/3.0
Base
Std
HL7 V2.5
Biosurveillance Technical Committee Recommendations
cd Bio Interoperability Specification
«component»
Resource Utilization
Message
«interoperability specification»
Bio-surv eillance
contains
+
+
«transaction»
Pseudonimize
contains
docId: = IS-02
+
docId: = ISC-47
docId: = IST-24
contains
contains
+
+
+
«transaction package»
Manage Sharing of
Documents
+
«composite standard»
IHE XDS-I
docId: = ISC-36
+
constrains
constrains
«composite standard»
IHE RFD
contains
constraints
«transaction»
Patient ID CrossReferencing
«component»
Lab Report
Document Structure
docId: = ISTP-13
docId: = ISTP-50
docId: = ISC-45
references
+
docId: = ISC-37
«base standard»
XForms
docId: = IST-22
constrains
constrains
docId: = ISTP-49
implements
+
contains
«transaction package»
Retriev e Form for Data
Capture
«component»
Acknow ledgements
docId: = ISTP-48
+
docId: = IST-25
+
«component»
Lab Report
Message
contains
docId: = ISC-41
«transaction package»
Radiology Report
Document
contains
«transaction package»
Encounter Document
docId: = ISC-39
contains
contains
«component»
Encounter Message
«component»
Radiology Message
+
+
contains
contains
«transactions»
Anonymize
contains
«composite standard»
IHE XDS
«composite standard»
IHE PIX
«composite standard»
IHE XDS-MS
-
constrains
PIX Query: ITI-9
constrains
implements
«component»
EHR Lab
Terminology
references
+
docId: = ISC-35
constrains
implements
«base standard»
DICOM 2003
«composite standard»
IHE NAV
«base standard»
ISO 15000
ebRS 2.1/3.0
«composite standard»
IHE XDS Lab
+
Provide & Register Document Set: ITI-15
constrains
constrains
constrains
constrains
constrains
constrains
«base standard»
LOINC
«base standard»
HL7 CDA r2
«base standard»
HL7 V3 Lab
«base standard»
HL7 2.5
Message
constrains
constrains
constrains
«base standard»
HL7 2.5 Code
Sets
«base standards»
HL7 3.0 Code
Sets
«base standard»
SNOMED-CT
constrains
constrains
constrains
System Development Process
USER ROLE
System Development Process
System development activities
 Requirements Elicitation
 Design
 Analysis
 System
design
 Object design
Pilot testing
 Implementation
 Evaluation

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.
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
Requirement Elicitation
Functional requirements examples:
-
-
-
Support data collection (e.g., send data)
Store data
Manage data
Analyse data
Generate reports
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.
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
Non-Functional Requirements
Constraints or Pseudo Requirements
Implementation requirements
 Interface requirements
 Operation requirements
 System security requirements
 Packaging requirements
 Legal requirements

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.
System Requirements Specification Document: Outline
1. 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
Timeline and Deliverables
Month
1 2 3 4
Requirement Elicitation
System Development
Pilot Testing
System Implementation
System Evaluation
5 6 7 8 9 10 11 12 1 2 3 4 5 6
Requirement Analysis Document (RAD)
System Development Specification Document
Pilot Testing Protocol & Report
System Documentation Prototype
System Evaluation
Protocol & Report
System Operation
System Documentation &
Operational Manual
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
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
Billy
(Patient, Consumer,
Student)
Primary Care Provider
(PCP) &
Community Health Center
(CHC)
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
Receive 211S Form from ASHR
Automated School
Health Record
(ASHR)
Review student data
Billy’s
Parent/Guardian
Italic font &
represent future functions of
electronic data exchange
File student data into a
School Records System
Communicate to a Guardian and PCP via
ASHR and CHC EHRS regarding student
health concern
School Nurse &
School Record
System
Fig 1. UML Use Case Diagram – Scenario 1: Healthy Child
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
Amy
(Patient, Consumer,
Student)
Verify the Multi-Use Medication (MUM) Form
Sign Consent Form
Primary Care Provider
(PCP) &
Community Health Center
(CHC)
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
Receive 211S, RES and MUM Forms and Consent from
ASHR
Amy’s
Parent/Guardian
Automated School
Health Record
(ASHR)
Review student data
Store 211S, RES and MUM Forms and Consent in
Special Needs Database
Administer medication to student
Italic font &
represent future
functions of
electronic data
exchange
Update student’s record on the use of medication in
Special Needs Database
Submit student record to CHC EHRS via ASHR
Communicate to a Guardian and PCP via ASHR and
CHC EHRS regarding student health
School Nurse &
School Record
System &
Special Needs
Database
School Health: Current Work Flow and Data Flow Model:
Scenario 1- Healthy Child
Child with
parent visits
provider
Provider
completes
211S
Patient
Record
Parent
deliver 211S
to school
211S
Form
School nurse
enter 211S data
into ASHR
211S
Form
Reports
DOHMH
maintains
ASHR
211S
Form
211S
Form
ASHR
School DB
EHR
CHC EHRS
Reports
School Health: Current Work Flow and Data Flow Model:
Scenario 2- Child Has Asthma
Parent
completes
Consent
Form
Child with
parent visits
provider
Provider
completes
211S Form
Consent
Form
Parent
deliver
Forms
to school
211S
Form
Patient
Record
EHR
Consent
Form
School nurse
enter Forms
data
into ASHR
211S
Form
RES
Form
RES
Form
MUM
Form
MUM
Form
Reports
DOHMH
maintains
ASHR
School
Forms
School
Forms
ASHR
School DB
Reports
CHC EHRS
Community Health Centers
(CHC)
EHR
CHC-I
EHRS
EHR
CHC-II
EHRS
EHR
CHC-N
EHRS
New York City
Department of Health &
Mental Hygiene
School
Forms
211S
Form
Consent
RES
Form
MUM
Form
Form
Automated
Student Health
Record
(ASHR)
System
New York City
Schools
School
Forms
School-I
System
School
Forms
School-II
System
School
Forms
School-N
System
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?
Functional Requirements Specifications for
Electronic Data Exchange between
Clinical Care and Public Health
WHERE TO START?
Knowledge Management in Public Health
WHAT IS PUBLIC HEALTH?
Public Health Organization
Public health nowadays is:
 Agency
 Healthcare provider
 Laboratory
 Purchaser
 Payor
 Pharmacy
 Research
Public Health Organization
Public health nowadays is:
 Agency
 Healthcare provider
 Laboratory
 Purchaser
 Payor
 Pharmacy
 Research
Publicly-delivered
Healthcare Care
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.
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)
State Health Agencies
Functions
Responsibilities
of State
Health Agencies: 2001
Responsibilities
%
Responsibilities
%
State public health authority
97
Medical examiner
21
Public health laboratory
79
State mental health authority
19
Rural health
79
State public health licensing agency
17
Children with special healthcare
needs
77
State mental institution or hospital
17
Minority health
72
Partial/split responsibility for
Medicaid
17
Institutional licensing agency
60
Medicaid state agency
15
State health planning & development
agency
53
Lead environmental agency
15
Partial/split leadership of
environmental agency
51
State tuberculosis hospital
15
Public health pharmacy
34
Health insurance regulation
15
State nursing home
28
Source:Beitsch LM et al. Structure and functions of state public health agencies. APHA. 2006:96(1):167-72
Local Health Agencies
Responsibilities
of LocalFunctions
Public Health Agencies
Personal Health Services
(%)
Population Level Services
(%)
Adult Immunizations
91
Communicable Disease Control
94
Childhood Immunizations
89
Health Education
87
Tuberculosis Testing
88
Epidemiology and Surveillance
84
STD Testing and Counseling
65
High Blood Pressure Screening
81
HIV Testing and Counseling
64
Tobacco Use Reduction
68
EPSDT
59
Cancer Screening
58
Family Planning
58
Diabetes Screening
53
WIC
55
Cardiovascular Disease Screening
50
Prenatal Care
41
Injury Control
37
Dental Care
30
Violence Prevention
22
HIV Treatment
25
Occupational Safety and Health
13
Primary Care
18
Source: Scutchfield, F.D., & Keck, C.W. Principles of public health practice, 2nd ed. 2003. Thomson/Delmar
Learning: Clifton Park, NY.
All public health activities are supported by
customized information systems
(databases, registries) developed to
address the programmatic needs.
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.
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
Clinical – Public Health Data Exchanges: State Health Agencies
Genetic Disorder
Vital Statistics
Provider 1
Communicable
Diseases
Immunization
Provider 2
Provider 3
Lead and
Environmental
Epidemiology
Injury Control
School Health
Provider 4
Chronic Care
Biosurveilance, BT,
Preparedness
WIC
Provider X
Public Health
Laboratory
HEDIS
Cancer
Source: Beitsch et.al Structure and Function of State Public Health Care Agencies” / AJPH, January, 2006.
Clinical-Public Health Data Exchanges: Local / State / Federal
Health Agencies
Genetic Disorder
Vital Statistics
Health Education/Risk
Reduction
Provider 1
Communicable
Diseases
Provider 2
Immunization
EPSDT
Provider 3
Injury Control
Immunization
Lead Registry
Injury Control
School Health
School Health
Chronic Care
Chronic Care
Biosurveilance, BT,
Preparedness
Biosurveilance, BT,
Preparedness
WIC
WIC
Public Health
Laboratory
Occupational Safety
and Health
HEDIS
Provider 4
Provider X
Communicable
Diseases
Cancer
Source: Beitsch et.al AJPH, January, 2006.
CDC
HRSA
AHRQ
Paper-based Health Data Exchanges
Genetic Disorders
Provider 1
Provider 2
Communicable
Diseases
Immunization
Vital Records
Provider 3
Injury Control
Provider 4
School Health
Chronic Care
Provider X
Biosurveilance,
BT,
Preparedness
HEDIS
On average
49% of cases
got reported
(CDC, 2006).
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/s
EHR-PH System Prototype for Interoperability
Public
Health Surveillance
Clinical Care in 21st Century Health Care
System
Hospital of Birth
State Health Department
ADTBirth Record
HL7 2.4
Newborn
Screening
Test
Hearing
Screening
Test
Immunization
Administration
HL7 3.0
HL7 3.0
Newborn
Screening
Registry
HL7 3.0
EHR-PH
Info Exchange
HL7 3.0
HL7 2.4
Immunization
Registry
HL7 2.4
HL7 3.0
HL7 2.4
J2EE
External
Laboratory
Hearing
Screening
Registry
HTB
J2EE
Communicable
Disease
Registry
Wrtwertghghgghhghg
Wrtwrtghghghghgh
Wtrwtrghgg
Wrtwertghghgghhghg
Wrtwrtghghgh
Wrtwrtghghghghgh
Aadkalfjkaldkfjalkdjflajh
Wtrwtrghgg
jkhjkhjkhk
Wrtwrtghghgh
flkdjghghghghghghghgh
Aadkalfjkaldkfjalkdjflajk
flkdjghghghghghghghg
fhjfghjfh
Healthcare
Transaction
Viewer
HTB – Health Transaction Base
Source: Orlova, et al. HIMSS 2005,Dallas TX, February 13-17, 2005 and AMIA, Washington DC, November, 2005
EHR-PH
System
Prototype
forforInteroperability
EHR-PH
System
Prototype
Interoperability
Health Surveillance
Clinical
Care in 21stHealth
in 21st
Century
CenturyCare
HealthSystem
CarePublic
System
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
Towards EHR-PH Data Exchange: Clinical Care & Public Health
Genetic Disorders
Provider 1
Provider 2
Communicable
Diseases
Immunization
Vital Records
Provider 3
Injury Control
Provider 4
School Health
Chronic Care
Provider X
Biosurveillance, BT,
Preparedness, Syndromic
Surveillance
HEDIS
EHRExchange: Clinical Care & Public Health
Towards EHR-PH Data
EHR
CDA
Provider 1
(Clinical
Data
Architecture)
Provider 4
Communicable
Diseases
Immunization
Provider 2
Provider 3
Genetic Disorders
IHE
Vital Records
(Integrated
Healthcare
Enterprise)
Injury Control
LAB
School Health
Chronic Care
Provider X
Biosurveilance, BT,
Preparedness,
Syndromic Surveillance
HEDIS
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
NCPDP Script
ASTM/CCR
CDA Level 3 Coded Entries
(CCD/MS Entries)
•• Personal Information
•• Healthcare Provider
•• Insurance Provider
•• Allergies and Drug Sensitivity
•• Condition
•• Medications
•• Pregnancy
•• Advance Directives
CCD - Clinical Care Document, CDA Rel2– Clinical Data Architecture, Release 2,
CCR – Continuity Care Record
EHR-PH Data Exchange: Clinical & Public Health Systems
EHR
Genetic Disorders
Communicable
Diseases
Provider 1
CDA2
Provider 2
Immunization
Vital Records
Provider 3
X12
Provider 4
Injury Control
School Health
Chronic Care
NCPDP
Provider X
IHE
LAB
Biosurveilance, BT,
Preparedness,
Syndromic Surveillance
HEDIS
FORMS
EHR-PH Data Exchange: Clinical & Public Health Systems
EHR
Forms
Genetic Disorders
CDA2
Communicable
Diseases
Provider 1
Provider 2
IHE
LAB
Immunization
Vital Records
Provider 3
Injury Control
Provider 4
NCPDP
SH
School Health
Chronic Care
Provider X
X12
BT
Biosurveilance, BT,
Preparedness, Syndromic
Surveillance
HEDIS
EHR-PH Data Exchange: Clinical & Public Health Systems
EHR
Forms
NBS Genetic Disorders
CDA2
Provider 1
Provider 2
IHE
LAB
TB,
STD.
……
Communicable
Diseases
IR
Immunization
VR
Vital Records
Provider 3
ECIC Injury Control
Provider 4
NCPDP
SH
CVD,
Asthma
Diabetes
Provider X
X12
BT
School Health
Chronic Care
Biosurveilance, BT,
Preparedness, Syndromic
Surveillance
HEDIS
HEDIS
Functional Requirements Specifications for
Electronic Data Exchange between Clinical
Care and Public Health
WORKING WITH VENDOR COMMUNITY
Providers and Software Developers
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise
and Across Care Settings
WWW.IHE.NET
Integrating the Healthcare Enterprise (IHE)
Overview
Presented by Dan Russler, M.D., IHE
PCC Co-chair
IHE Workshop – June 19, 2006
Why IHE?



1970’s—Mainframe Era--$100,000 per interface
1990’s—HL7 2.x--$10,000 per interface
2000’s—IHE Implementation Profiles—
Cheaper than a new phone line!
How? IHE Eliminates Options Found in
Published Standards
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,
SCA&I, HRS and more
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
Electronic Health Record
Radiology
Cardiology
14 Integration Profiles
4 Integration Profiles
IHE
IT Infrastructure
Laboratory
5 Integration Profiles
Patient Care
Coordination
1 Integration Profile
13 Integration Profiles
Future
Domains
Patient Care
Devices
Pathology
Eye Care
Oncology
IHE Standards-Based Integration Solutions
Professional 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
Profile
Solution
Specifications
Interoperable
Healthcare IT
IHE Integration
Profile
Solution
Specifications
IHE Integration
Profile
IHE in 2006 – 18 Month Development Cycles
•
First Cycle:
•
•
•
•
•
•
•
•
•
Planning Committee Proposals:
Technical Committee Drafts:
Public Comment Due:
Trial Implementation Version:
Mesa Tool Test Results Due:
IHE Connectathon:
HIMSS Demo:
Participant Comments Due:
Final Implementation Version:
November, 2005*
June, 2006*
July 2006
August 2006
December 2006
January 2007
February 2007
March 2007
June 2007
IHE Technical Frameworks
Department System
Scheduler/
Order Filler
Order
Placer
ADT
Image
Manager/
PPS Manager
Acquisition
Modality
Register J.Doe
Patient
Registration [RAD-1]
Placer Order
Management–
New [RAD-2]
One or the
other methods
of creating an
order is used
Filler Order
Management New [RAD-3]
Schedule
Procedure
Procedure
Scheduled [RAD-4]
Query Modality Worklist [RAD-5]
Filler Order
Mgmt - Status
Update [RAD-3]
Patient Reconciliation
J.Doe ->
J.Smith
ADT
Pt. Registration [RAD-1] 
Patient Update [RAD-12] 
DSS/ Order Filler
Patient Update/
Merge [RAD-12]
 Pt. Registration [RAD-1]
 Patient Update [RAD-12]
 Placer Order Management [RAD-2]
 Filler Order Management [RAD-3]
 Modality PS in Progress [CARD-1]
 Modality PS Completed [RAD-7]
Filler Order
Mgmt - Status
Update [RAD-3]
Modality Procedure
Step In Progress
[CARD-1]
Modality Procedure
Step Completed
[RAD-7]
Modality Procedure
Step In Progress
[CARD-1]
Modality Procedure
Step Completed
[RAD-7]
Patient Update/
Merge [RAD-12]
Order Placer
 Procedure Scheduled [RAD-4]
 Patient Update [RAD-12]
 Procedure Updated [RAD-13]
 Instance Availability Notification [RAD-49]
Evidence
Creator
 Modality PS in Progress [CARD-1]
 Modality PS Completed [RAD-7]
Detailed standards implementation
guides
Performed
Procedure
Step Manager
Storage 
Commitment
[CARD-3]
Image Display
 Modality Image/Evidence
Stored [CARD-2]
Image
Manager
Image
Archive
 Modality PS in Progress [CARD-1]
 Modality PS Completed [RAD-7]
Storage
Commitment 
[CARD-3]
Modality Image/Evidence
Stored [CARD-2]
 Modality PS in Progress [CARD-1]
 Modality PS Completed [RAD-7]
 Query Modality Worklist [RAD-5]
Acquisition
Modality
 Query Images [RAD-14]
 Retrieve Images/Evidence [CARD-4]
Perform
Acquisition
HIMSS IHE Interoperability Showcase
February 2006 Participants
Leadership Level
Blue Ware
Cerner
GE Healthcare +IDX
IBM
Initiate Systems
InterSystems
MiSys Healthcare
Quovadx
Siemens
Supporter
Level:
Acuo
Bond
Carefx
Clearcube
Dairyland
EMC
Identrus
Intel
Mediserve
Implementer Level
Allscripts
Canon
CapMed
Cardiac Science
CGI-AMS
CompassCare
CPSI
Dictaphone
DR Systems
Eastman Kodak
Eclipsys
Epic Systems
HIPAAT
Medkey
Motion
Comp.
Picis
Pulse
HX Technologies
INFINITT Technology
Kryptiq
McKesson
MedAccess Plus
Medical Informatics
MediNotes
MNI
National Institute of Sci & Tech
NextGen Healthcare
Philips Medical
ScImage
Witt Biomedical
DMP–French Natl. Personal
EHR
HTP
American Coll. of Clinical Eng. Health Level 7
IEEE
Catholic Healthcare West
Midmark Diagostics Group
US Dept of Defense
HIMSS RHIO Federation
US Dept of Veterans Affairs Liberty Alliance
Organizational participant:
IHE Connectathon, January 2006
•300+ participants, 120+ systems
•60+ systems developers
•Four Domains: Cardiology, IT Infrastructure,
Patient Care Coordination, Radiology
•2800+ monitored test cases

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
IHE Integration Profiles for Health Info Nets
What is available and has been added in 2005 and is for 2006
Clinical and PHR
Content
Emergency Referrals
PHR Extracts/Updates
Format of the Document Content
andReport
associated
coded vocabulary
ECG
Document
Format
of the Document
Content
and
associated
coded
vocabulary
Lab
Results Document
Format of the Document Content
Content
Scanned
Documents
and associated
coded vocabulary
Format of the Document Content
Imaging
and associated
coded vocabulary
Format
of theInformation
Document
Content
Medical Summary
Format of the Document Content
Allergies,
Pbs)
and(Meds,
associated
coded
vocabulary
Format of the Document Content
and associated coded vocabulary
Health Data Exchange
Cross-Enterprise
Document Sharing
Registration, distribution and access
across health enterprises of clinical
documents forming a patient
electronic health record
Cross-enterprise Document
Point-Point Interchange
Media-CD/USB & e-mail push
Security
Basic Patients Privacy
Consents
Establish Consents & Enable
Access Control
Document Digital
Signature
Patient Id Mgt
Patient Demographics
Query
Patient Identifier
Cross-referencing
Map patient identifiers across
independent identification
domains
Attesting “true-copy and origin
Audit Trail & Node
Authentication
Centralized privacy audit trail and node
to node authentication to create a
secured domain.
Other
Request Form
for Data Capture
External form with custom
import/export scripting
Consistent Time
Coordinate time across networked
systems
Notification of
Document Availability
Notification of a remote
provider/ health enterprise
HITSP
Biosurveillance
AHIC-ONC BIO Consolidated Use Case
Patient-Level Data to Public Health
Document-based Submission
Biosurveillance – Patient-level and Resource Utilization Interoperability Specification
Transaction Package
Consumer/Patient Id X-ref
Transaction Package
Manage Sharing of
Docs
Document-based
Scenario
Transaction
Notif of Doc Availability
IHE
XDS-I
Base
Std
HL7
QBP^Q23
RSP^K23
Transaction
Pseudonymize
IHE
NAV
IHE
XDS
IHE
PIX
PDQ
Component
Lab Report Document
Component
Anonymize
Component
Lab Terminology
Base
Std
DICOM
Base
Std
LOINC
SNOMEDCT
IHE
XDS-MS
Base
Std
HL7
CDA r2
IHE
XDS-LAB
Terminology
Standards
HCPCS HL7 V3
CPT HL7 V2.5
CCC SNOMED-CT
ICD 9/10 LOINC
NCCLS
UCUM
UB-92
URL
FIPS 5-2
HAVE
Base
Std
ISO
DTS/
25237
HIPAA
DICOM
Base
Std
ISO 15000
ebRS 2.1/3.0
Base
Std
HL7 V2.5
Providers and Software Developers
Working Together to Deliver
Interoperable Health Information Systems
in the Enterprise
and Across Care Settings
PHDSC was Invited to Sponsor
Public Health Domain at IHE
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

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?
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 (HIMSS’s 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
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
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.