Briefing For Public Health Data Standards Consortium Presented by: Holt Anderson Arlington, VA
Public Health Data Standards Consortium
description
Transcript of Public Health Data Standards Consortium
Public Health Data Standards Consortium http://www.phdsc.org
PHDSC/HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES
December 5-6, 2006, Washington DC
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES
GoalThe 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
PANELISTSDr. Oxiris Barbot, NYC Department of Health and Mental Hygiene, NYDr. Neil Calman, Institute for Urban Family Health, NYC, NY Ms. Kathleen Cook, Lincoln-Lancaster County Health Deptment (City of
Lincoln, County of Lancaster), NEDr. Art Davisson, Denver Public Health, CODr. 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, MNDr. David Lawton, Nebraska Health and Human Services System, NEDr. Farzad Mostashari, NYC Dept. of Health & Mental Hygiene, NYCDr. Anna Orlova, Public Health Data Standards ConsortiumDr. David Ross, Public Health Informatics InstituteDr. 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 TownsendDr. Michael Millman
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES
DAY 1December 5, 2006
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES
AGENDADAY 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, PHDSCParticipants: Invited Panelists and Guests
ROUNDTABLE DISCUSSIONModerator: 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. Public Health Agencies efforts presented are targeted to specific programs, e.g., immunization.
2. 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.
3. Functional requirements and other standards are needed to move things along.
4. 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.
5. Public health activities discussed: immunization, registries.6. Business cases are not only about monetary value.7. 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 2December 6, 2006
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES
AGENDADAY 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
AGENDADAY 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 OrlovaPHDSC
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES
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 enableRegional Health Information Exchanges (RHIEs) organized viaRegional 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.
RHIOs as NHIN ComponentsSource: Dr. Peter Elkin, Mayo Clinic, MN, 2006
PHDSC Involvement
Healthcare Information Technology
Standards Panel (HITSP)
Nationwide Health
Information Network (NHIN)
Architecture Projects
The Health Information Security and
Privacy Collaboration
(HISPC)
The Certification Commission for
Healthcare Information Technology
(CCHIT)American Health
Information Community
(Community)
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
NHIN Development Process
URL: http://www.hhs.gov/healthit/ahic.html
Arlington, VASeptember 20, 2006
Standards Harmonization Technical Committees UpdateReport to the Healthcare Information Technology Standards Panel
Discussion Document
Contract HHSP23320054103EC
HITSP includes 206 member organizations:
17 SDOs (8%) 161 Non-SDOs (79%) 18 Govt. bodies (8%)
10 Consumer groups (5%)
US Health Care System Standardization: 2005-now
HITSP Standards Categories – Feb 2006
1. Data Standards (vocabularies and terminologies)
2. Information Content Standards (RIMs)3. Information Exchange Standards4. Identifiers Standards5. Privacy and Security Standards6. Functional Standards7. Other
HITSP definition
The Community identified 3 breakthrough areas for the NHIN development process in 2006:
Biosurveillance Consumer Empowerment Electronic Health Record
Standard Harmonization Process
* 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
Laboratory
Ambulatory Care
PharmacyResponse
Team
State Public HealthSurveillance System
Event Detection
DHHS
4- Report/retrieve of symptoms,diagnosis & medication prescription data from EHRS
4 – Data mining of EMR notes
7 – Notify on increased number
of cases & recommend to
order specific tests
9 – Ordertest
11 – Reporttest result
electronically & by phone
13 – Report on the positive case electronically & by phone
Media
LocalPublic HealthSurveillance
System
HospitalNeighboringJurisdictions
PUBLIC
AHIC Biosurveillance Use Case
AHIC-ONC BIO Consolidated Use Case
BaseStd
HL7 V2.5
BiosurveillancePatient-level data to Public Health
Message-based Submission
Transaction PackageConsumer/Patient Id X-ref
IHEPIXPDQ
IHEXDS
BaseStd
ISO 15000ebRS 2.1/3.0
HITSP
ComponentAnonymize
TransactionPseudonymize
BaseStdISO
DTS/25237
HIPAADICOM
ComponentLab Report Message
ComponentLab Terminology
BaseStd
LOINC
ComponentEncounter Msg
ComponentRadiology Msg
BaseStd
HL7V2.5ADT^xxx
HCPCS CPT
CCCICD 9/10
NCCLS UB-92 FIPS 5-2
HL7 V3
HL7 V2.5SNOMED-CT
LOINC UCUM
HAVE
TerminologyStandards
URL
SNOMED-CT
BaseStd
HL7V2.5ORU^R01
Message-basedScenario
Biosurveillance – Patient-level and Resource Utilization Interoperability Specification
BaseStdHL7
QBP^Q23RSP^K23
AHIC-ONC BIO Consolidated Use Case
ComponentLab Report Document
BaseStd
HL7 V2.5
BiosurveillancePatient-Level Data to Public Health
Document-based Submission
IHEPIXPDQ
IHEXDS
BaseStdHL7
CDA r2
IHE XDS-LAB
BaseStd
ISO 15000ebRS 2.1/3.0
Transaction PackageManage Sharing of Docs
TransactionNotif of Doc Availability
IHE NAV
ComponentLab Terminology
BaseStd
LOINC
HITSP
IHE XDS-MS
IHE XDS-I
BaseStd
DICOMHCPCS
CPT
CCCICD 9/10
NCCLS UB-92 FIPS 5-2
HL7 V3
HL7 V2.5SNOMED-CT
LOINC UCUM
HAVE
TerminologyStandards
URL
SNOMED-CT
Document-basedScenario
Transaction PackageConsumer/Patient Id X-ref
ComponentAnonymize
TransactionPseudonymize
BaseStdISODTS/25237
HIPAADICOM
Biosurveillance – Patient-level and Resource Utilization Interoperability Specification
BaseStdHL7
QBP^Q23RSP^K23
Biosurveillance Technical Committee Recommendationscd Bio Interoperability Specification
«interoperabil ity specification»Bio-surv eillance
+ docId: = IS-02
«transaction»Pseudonimize
+ docId: = IST-24
«transactions»Anonymize
+ docId: = IST-25
«component»Resource Utilization
Message
+ docId: = ISC-47
«component»Encounter Message
+ docId: = ISC-39
«component»Radiology Message
+ docId: = ISC-41
«composite standard»IHE PIX
- PIX Query: ITI-9
«base standard»HL7 2.5
Message
«component»Lab Report
Document Structure
+ docId: = ISC-37
«composite standard»IHE XDS Lab
+ Provide & Register Document Set: ITI-15
«composite standard»IHE XDS
«base standard»ISO 15000
ebRS 2.1/3.0
«base standard»HL7 CDA r2
«base standard»HL7 V3 Lab
«component»Lab Report
Message
+ docId: = ISC-36
«component»EHR Lab
Terminology
+ docId: = ISC-35
«composite standard»IHE NAV
«component»Acknowledgements
+ docId: = ISC-45
«transaction package»Radiology Report
Document
+ docId: = ISTP-49
«transaction package»Retriev e Form for Data
Capture
+ docId: = ISTP-50
«composite standard»IHE RFD
«base standard»XForms
«transaction package»Encounter Document
+ docId: = ISTP-48
«composite standard»IHE XDS-MS
«composite standard»IHE XDS-I
«base standard»DICOM 2003
«base standard»LOINC
«base standard»SNOMED-CT
«base standard»HL7 2.5 Code
Sets
«base standards»HL7 3.0 Code
Sets
«transaction»Patient ID Cross-
Referencing
+ docId: = IST-22
«transaction package»Manage Sharing of
Documents
+ docId: = ISTP-13
contains
implements
constrains
contains
constrainsconstrains
constrains
constrains
constrains
constrains
contains
contains
constrains
contains
constrains
constrains constrains
constrains
contains
contains
references
contains
constrains
constrains
constrains
references
constrains
constrains
implements
constrains
constraints
constrains
contains
contains
contains
contains
contains
implements
USER ROLE
System Development Process
System development activities Requirements Elicitation Design
AnalysisSystem designObject design
Pilot testing Implementation Evaluation
System Development Process
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 – User Role
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
Requirements 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.
Requirement Elicitation
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
Non-Functional Requirements
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.
Work Products: Deliverables
System Requirements Specification Document: Outline
1. Introduction (Problem Overview)1.1 Purpose of the Proposed System1.2 Actors and Scope of the Proposed System1.3 Objectives and Success Criteria of the Project
2. System Requirements2.1 Functional requirements2.3 Non-functional requirements
3. System Models3.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 Architecture4. Project Development Timeline5. Testing / Evaluation Plan
Timeline and Deliverables
Requirement ElicitationSystem DevelopmentPilot TestingSystem ImplementationSystem EvaluationSystem Operation
Month1 2 3 4 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 Documentation & Operational Manual
System Evaluation Protocol & Report
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
Export 211S Form into ASHR
Verify 211S Form
Update Personal Health Record (PHR) - My Chart
Receive 211S Form from CHC EHRS
Send 211S Form to a School
Receive 211S Form from ASHR
Review student data
File student data into a School Records System
Communicate to a Guardian and PCP via ASHR and CHC EHRS regarding student
health concern
Fig 1. UML Use Case Diagram – Scenario 1: Healthy Child
Billy(Patient, Consumer,
Student)
Billy’s Parent/Guardian
Primary Care Provider (PCP) &
Community Health Center (CHC)
Automated School Health Record
(ASHR)
School Nurse &School Record
System
Print 211S Form
Italic font &represent future functions of electronic data exchange
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
Export 211S, RES and MUM Forms and Consent to ASHR
Update Personal Health Record (PHR) - My Chart
Receive 211S, RES and MUM Forms and Consent from CHC EHRS
Send 211S, RES and MUM Forms and Consent to a School
Submit student record to CHC EHRS via ASHR
Review student data
Administer medication to student
Verify the Request for Educational Services (RES) Form
Print 211S, RES and MUM Forms
Store 211S, RES and MUM Forms and Consent in Special Needs Database
Update student’s record on the use of medication in Special Needs Database
Receive 211S, RES and MUM Forms and Consent from ASHR
Amy (Patient, Consumer,
Student)
Amy’s Parent/Guardian
Automated School Health Record
(ASHR)
Primary Care Provider (PCP) &
Community Health Center (CHC)
School Nurse &School Record
System &Special Needs
Database
Verify the Multi-Use Medication (MUM) Form
Communicate to a Guardian and PCP via ASHR and CHC EHRS regarding student health
Verify 211S Form
Sign Consent Form
Italic font &represent future functions of electronic data exchange
School Health: Current Work Flow and Data Flow Model: Scenario 1- Healthy Child
CHC EHRS Reports
ReportsChild with parent visits
provider
Provider completes
211S
Parent deliver 211S
to school
Patient Record
School DB
School nurse enter 211S data
into ASHR
ASHR
211SForm
DOHMHmaintains
ASHR
211SForm
211SForm
211SForm
EHR
School Health: Current Work Flow and Data Flow Model: Scenario 2- Child Has Asthma
CHC EHRS
Reports
ReportsChild with parent visits
provider Provider completes211S Form
Parent deliver Forms
to school
Patient Record
School DB
School nurse enter Forms
data into ASHR
ASHR
SchoolForms
DOHMHmaintains
ASHR
211SForm
SchoolForms
EHR
RESForm
MUMForm
ConsentFormParent
completesConsent
Form
211SForm
RESForm
MUMForm
ConsentForm
CHC-I EHRS
EHR
Community Health Centers(CHC) New York City
Department of Health & Mental Hygiene
AutomatedStudent Health
Record (ASHR)System
SchoolForms
School-IISystem
SchoolForms
School-NSystem
SchoolForms
School-ISystem
SchoolForms
New York CitySchools
CHC-II EHRS
EHR
CHC-NEHRS
EHR
211SForm
RESForm
MUMForm
ConsentForm
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
Functional Requirements Specifications for Electronic Data Exchange between
Clinical Care and Public Health
WHERE TO START?
WHAT IS PUBLIC HEALTH?
Knowledge Management in Public Health
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
Public Health Organization
Publicly-delivered Healthcare Care
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 Organization
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)
Public Health Information Systems
Responsibilities of State Health Agencies: 2001
Responsibilities % Responsibilities %State public health authority 97 Medical examiner 21Public health laboratory 79 State mental health authority 19Rural health 79 State public health licensing agency 17Children 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 15State 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 15State nursing home 28
Source:Beitsch LM et al. Structure and functions of state public health agencies. APHA. 2006:96(1):167-72
State Health Agencies Functions
Responsibilities of Local 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 13Primary Care 18
Source: Scutchfield, F.D., & Keck, C.W. Principles of public health practice, 2nd ed. 2003. Thomson/Delmar Learning: Clifton Park, NY.
Local Health Agencies Functions
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 are23 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/systemsSo roughly, there are over 70 thousands public
health information systems -- all of them are customized, siloed systems.
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Clinical – Public Health Data Exchanges: Local Health Agencies
Communicable Diseases
Immunization
EPSDT
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness
WIC
Health Education/Risk Reduction
Occupational Safety and Health
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Cancer
HEDIS
Public Health Laboratory
Clinical – Public Health Data Exchanges: State Health Agencies
Vital Statistics
Communicable Diseases
Immunization
Lead and Environmental Epidemiology
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness
Genetic Disorder
WIC
Source: Beitsch et.al Structure and Function of State Public Health Care Agencies” / AJPH, January, 2006.
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Cancer
HEDIS
Public Health Laboratory
Clinical-Public Health Data Exchanges: Local / State / Federal Health Agencies
Vital Statistics
Communicable Diseases
Immunization
Lead Registry
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness
Genetic Disorder
WIC
Communicable Diseases
Immunization
EPSDT
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness
WIC
Health Education/Risk Reduction
Occupational Safety and Health
Source: Beitsch et.al AJPH, January, 2006.
HRSA
AHRQ
CDC
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Communicable Diseases
Immunization
Vital Records
Injury Control
School Health
Chronic Care
Biosurveilance, BT,
Preparedness
Genetic Disorders
HEDIS
Paper-based Health Data Exchanges
On average49% 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/ss1000-ol.pdf.
Clinical Care
ADT-Birth Record
Newborn Screening Test
HearingScreening Test
Immunization Administration
External Laboratory
Hospital of Birth
HL7 2.4
HL7 3.0
HL7 3.0
HL7 2.4
HL7 2.4
Public Health Surveillance
EHR-PHInfo Exchange
NewbornScreeningRegistry
Hearing ScreeningRegistry
ImmunizationRegistry
CommunicableDiseaseRegistry
HTB
State Health Department
WrtwertghghgghhghgWrtwrtghghghghghWtrwtrghggWrtwrtghghghAadkalfjkaldkfjalkdjflajhjkhjkhjkhkflkdjghghghghghghghgh
WrtwertghghgghhghgWrtwrtghghghghghWtrwtrghggWrtwrtghghghAadkalfjkaldkfjalkdjflajkflkdjghghghghghghghgfhjfghjfh
HealthcareTransactionViewer
HL7 3.0
HL7 3.0
HL7 2.4
HL7 3.0
J2EE
J2EE
HTB – Health Transaction Base
EHR-PH System Prototype for Interoperability in 21st Century Health Care System
Source: Orlova, et al. HIMSS 2005,Dallas TX, February 13-17, 2005 and AMIA, Washington DC, November, 2005
EHR-PH System Prototype for Interoperability
in 21st Century Health Care SystemOur 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
Clinical Care Public Health SurveillanceEHR-PH System Prototype for Interoperability
in 21st Century Health Care System
Towards EHR-PH Data Exchange: Clinical Care & Public Health
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Communicable Diseases
Immunization
Vital Records
Injury Control
School Health
Chronic Care
Biosurveillance, BT, Preparedness, Syndromic
Surveillance
Genetic Disorders
HEDIS
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Communicable Diseases
Immunization
Vital Records
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness,
Syndromic Surveillance
Genetic Disorders
HEDIS
EHR
CDA(Clinical
DataArchitecture)
IHE(IntegratedHealthcare Enterprise)
LAB
EHR
Towards EHR-PH Data Exchange: Clinical Care & Public Health
HITSP Registration & Medication History Document
CDA Rel2
CDA Level 3 Coded Entries(CCD/MS Entries)
•• Personal Information•• Healthcare Provider•• Insurance Provider•• Allergies and Drug Sensitivity•• Condition•• Medications•• Pregnancy•• Advance Directives
ASTM/HL7 CCD Based Document
CDA Level 2 Human Rendering
(CCD Loinc Section Codes)
CDA Level 1 Header
HL7 CCD/CRS Implementation Guide
X12 X271
NCPDP Script
ASTM/CCR
CCD - Clinical Care Document, CDA Rel2– Clinical Data Architecture, Release 2, CCR – Continuity Care Record
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Communicable Diseases
Immunization
Vital Records
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness,
Syndromic Surveillance
Genetic Disorders
HEDIS
EHR
CDA2
IHELAB
X12
NCPDP
EHR-PH Data Exchange: Clinical & Public Health Systems
FORMS
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Communicable Diseases
Immunization
Vital Records
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness, Syndromic
Surveillance
Genetic Disorders
HEDIS
EHR
CDA2
IHELAB
X12
NCPDPSH
BT
Forms EHR-PH Data Exchange: Clinical & Public Health Systems
Provider 1
Provider 2
Provider 3
Provider 4
Provider X
Communicable Diseases
Immunization
Vital Records
Injury Control
School Health
Chronic Care
Biosurveilance, BT, Preparedness, Syndromic
Surveillance
Genetic Disorders
HEDIS
EHR
CDA2
IHELAB
X12
NCPDP
NBS
TB, STD.……
IR
VR
ECIC
SH
CVD, Asthma
Diabetes
BT
HEDIS
Forms EHR-PH Data Exchange: Clinical & Public Health Systems
Functional Requirements Specifications for Electronic Data Exchange between Clinical
Care and Public Health
WORKING WITH VENDOR COMMUNITY
W W W . I H E . N E TW W W . I H E . N E T
Providers and Software DevelopersWorking Together to Deliver
Interoperable Health Information Systemsin the Enterprise
and Across Care Settings
Presented by Dan Russler, M.D., IHE PCC Co-chair IHE Workshop – June 19, 2006
Integrating the Healthcare Enterprise (IHE) Overview
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
Electronic Health Record
Cardiology
Laboratory
Radiology
Oncology
Future Domains
IHE
IT Infrastructure
14 Integration Profiles
5 Integration Profiles
4 Integration Profiles
1133 IInntteeggrraattiioonn PPrrooffiilleess
Patient Care Coordination
1 Integration Profile
Patient Care
Devices
Pathology Eye Care
IHE 2006 – Nine Active Domains IHE 2006 – Nine Active Domains Over 100 vendors involved world-wide,Over 100 vendors involved world-wide, 5 Technical 5 Technical
FrameworksFrameworks37 Integration Profiles, Testing at Connectathons37 Integration Profiles, Testing at ConnectathonsDemonstrations at major conferences world-wideDemonstrations at major conferences world-wide
15 Active national chapters on 4 continents15 Active national chapters on 4 continents
IHE Standards-Based Integration Solutions IHE Standards-Based Integration Solutions
Professional Societies Sponsorship Healthcare Providers & Software Developers
Healthcare IT Standards
HL7, DICOM, etc. General IT Standards
Internet, ISO, etc.
Interoperable Healthcare IT Solution Specifications
IHE Integration Profile Interoperable Healthcare IT
Solution Specifications IHE Integration Profile
Interoperable Healthcare IT Solution Specifications
IHE Integration Profile Interoperable Healthcare IT
Solution Specifications IHE Integration Profile
IHE Process
IHE in 2006 – 18 Month Development Cycles IHE in 2006 – 18 Month Development Cycles
• First Cycle:First Cycle:• Planning Committee Proposals:Planning Committee Proposals: November, 2005*November, 2005*• Technical Committee Drafts: Technical Committee Drafts: June, 2006*June, 2006*• Public Comment Due:Public Comment Due: July 2006July 2006• Trial Implementation Version: Trial Implementation Version: August 2006August 2006• Mesa Tool Test Results Due:Mesa Tool Test Results Due: December 2006December 2006• IHE Connectathon: IHE Connectathon: January 2007January 2007• HIMSS Demo: HIMSS Demo: February 2007February 2007• Participant Comments Due:Participant Comments Due: March 2007March 2007• Final Implementation Version: Final Implementation Version: June 2007June 2007
IHE Technical Frameworks
Pt. Registration [RAD-1] Patient Update [RAD-12]
Pt. Registration [RAD-1] Patient Update [RAD-12]
Placer Order Management [RAD-2] Filler Order Management [RAD-3]
ADT
Query Images [RAD-14] Retrieve Images/Evidence [CARD-4]
Image Display
Modality Image/Evidence Stored [CARD-2]
Storage Commitment
[CARD-3]
Procedure Scheduled [RAD-4]
Procedure Updated [RAD-13]
Query Modality Worklist [RAD-5]
Performed Procedure
Step Manager
Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7]
Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7]
Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7]
Order Placer
Acquisition Modality
ImageManager
ImageArchive
DSS/ Order Filler
Patient Update [RAD-12]
Modality Image/Evidence Stored [CARD-2]
Storage Commitment
[CARD-3]
Evidence Creator Modality PS in Progress [CARD-1]
Modality PS Completed [RAD-7]
Instance Availability Notification [RAD-49]
Pt. Registration [RAD-1] Patient Update [RAD-12]
Pt. Registration [RAD-1] Patient Update [RAD-12]
Placer Order Management [RAD-2] Filler Order Management [RAD-3]
ADT
Query Images [RAD-14] Retrieve Images/Evidence [CARD-4]
Image Display
Modality Image/Evidence Stored [CARD-2]
Storage Commitment
[CARD-3]
Procedure Scheduled [RAD-4]
Procedure Updated [RAD-13]
Query Modality Worklist [RAD-5]
Performed Procedure
Step Manager
Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7]
Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7]
Modality PS in Progress [CARD-1] Modality PS Completed [RAD-7]
Order Placer
Acquisition Modality
ImageManager
ImageArchive
DSS/ Order Filler
Patient Update [RAD-12]
Modality Image/Evidence Stored [CARD-2]
Storage Commitment
[CARD-3]
Evidence Creator Modality PS in Progress [CARD-1]
Modality PS Completed [RAD-7]
Instance Availability Notification [RAD-49]
Query Modality Worklist [RAD-5]
ADT Order Placer
Register J.Doe
AcquisitionModality
Placer OrderManagement –New [RAD-2]
Patient Reconciliation
Department System Scheduler/Order Filler
Schedule Procedure
Procedure Scheduled [RAD-4]
Modality Procedure Step Completed [RAD-7]J.Doe ->
J.Smith
Patient Update/Merge [RAD-12]
Modality Procedure Step Completed [RAD-7]
PatientRegistration [RAD-1]
Patient Update/Merge [RAD-12]
Modality Procedure Step In Progress [CARD-1]
Modality Procedure Step In Progress [CARD-1]
Perform Acquisition
Filler Order Mgmt - Status Update [RAD-3]
Filler Order Mgmt - Status Update [RAD-3]
ImageManager/
PPS Manager
Filler Order Management -New [RAD-3]
One or the other methods of creating an order is used
Query Modality Worklist [RAD-5]
ADT Order Placer
Register J.Doe
AcquisitionModality
Placer OrderManagement –New [RAD-2]
Patient Reconciliation
Department System Scheduler/Order Filler
Schedule Procedure
Procedure Scheduled [RAD-4]
Modality Procedure Step Completed [RAD-7]J.Doe ->
J.Smith
Patient Update/Merge [RAD-12]
Modality Procedure Step Completed [RAD-7]
PatientRegistration [RAD-1]
Patient Update/Merge [RAD-12]
Modality Procedure Step In Progress [CARD-1]
Modality Procedure Step In Progress [CARD-1]
Perform Acquisition
Filler Order Mgmt - Status Update [RAD-3]
Filler Order Mgmt - Status Update [RAD-3]
ImageManager/
PPS Manager
Filler Order Management -New [RAD-3]
One or the other methods of creating an order is used
Detailed standards implementation guides
HIMSS IHE Interoperability ShowcaseFebruary 2006 Participants
Leadership Level
Blue WareCernerGE Healthcare +IDX IBMInitiate SystemsInterSystems MiSys Healthcare Quovadx Siemens
Implementer LevelAllscriptsCanonCapMedCardiac ScienceCGI-AMS CompassCareCPSI DictaphoneDR SystemsEastman KodakEclipsys Epic SystemsHIPAAT
HX TechnologiesINFINITT TechnologyKryptiqMcKesson MedAccess PlusMedical Informatics MediNotes MNINational Institute of Sci & TechNextGen Healthcare Philips Medical ScImageWitt Biomedical
Supporter Level:
AcuoBondCarefxClearcube
DairylandEMCIdentrusIntelMediserve
Medkey Motion Comp.PicisPulseSentillion
Organizational participant:
American Coll. of Clinical Eng.Catholic Healthcare WestUS Dept of DefenseUS Dept of Veterans Affairs
DMP–French Natl. Personal EHRHealth Level 7 HTP IEEEMidmark Diagostics GroupHIMSS RHIO FederationLiberty AllianceUniv. of Washington
IHE Connectathon, January 2006•300+ participants, 120+ systems300+ participants, 120+ systems•60+ systems developers60+ systems developers•Four Domains: Cardiology, IT Infrastructure, Four Domains: Cardiology, IT Infrastructure,
Patient Care Coordination, RadiologyPatient Care Coordination, Radiology•2800+ monitored test cases2800+ monitored test cases
ResultsOver 3000 attendees visited the HIMSS RHIO
Showcase37 vendors demonstrated 48 systems700 attendees created and tracked their own
health record63 educational sessions were presented5 International delegations3 VIP tours16 clinical scenarios were demonstrated
IHE Integration Profiles for Health Info NetsWhat is available and has been added in 2005 and is for 2006
Patient Demographics Query
Patient Identifier Cross-referencing
Map patient identifiers across independent identification
domains
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
Emergency Referrals Format of the Document Content
and associated coded vocabulary
PHR Extracts/Updates
Format of the Document Content and associated coded vocabulary
ECG Report Document
Format of the Document Content and associated coded vocabulary
Lab Results Document Content
Format of the Document Content and associated coded vocabulary
Scanned Documents Format of the Document ContentImaging Information
Format of the Document Content and associated coded vocabulary
Medical Summary (Meds, Allergies, Pbs)
Format of the Document Contentand associated coded vocabulary
Consistent TimeCoordinate time across networked
systems
Audit Trail & Node Authentication
Centralized privacy audit trail and node to node authentication to create
a secured domain.
Basic Patients Privacy Consents
Establish Consents & Enable Access Control
Document Digital Signature
Attesting “true-copy and origin
Notification of Document Availability
Notification of a remote provider/ health enterprise
Request Formfor Data Capture
External form with custom import/export scripting
Patient Id MgtPatient Id MgtSecuritySecurityClinical and PHRClinical and PHRContentContent
Health Data ExchangeHealth Data Exchange OtherOther
AHIC-ONC BIO Consolidated Use Case
ComponentLab Report Document
BaseStd
HL7 V2.5
BiosurveillancePatient-Level Data to Public Health
Document-based Submission
IHEPIXPDQ
IHEXDS
BaseStdHL7
CDA r2
IHE XDS-LAB
BaseStd
ISO 15000ebRS 2.1/3.0
Transaction PackageManage Sharing of Docs
TransactionNotif of Doc Availability
IHE NAV
ComponentLab Terminology
BaseStd
LOINC
HITSP
IHE XDS-MS
IHE XDS-I
BaseStd
DICOMHCPCS
CPT
CCCICD 9/10
NCCLS UB-92 FIPS 5-2
HL7 V3
HL7 V2.5SNOMED-CT
LOINC UCUM
HAVE
TerminologyStandards
URL
SNOMED-CT
Document-basedScenario
Transaction PackageConsumer/Patient Id X-ref
ComponentAnonymize
TransactionPseudonymize
BaseStdISODTS/25237
HIPAADICOM
Biosurveillance – Patient-level and Resource Utilization Interoperability Specification
BaseStdHL7
QBP^Q23RSP^K23
PHDSC was Invited to Sponsor PHDSC was Invited to Sponsor Public Health Domain at IHEPublic Health Domain at IHE
Providers and Software DevelopersWorking Together to Deliver
Interoperable Health Information Systemsin the Enterprise
and Across Care Settings
PHDSC was Invited to Sponsor PHDSC was Invited to Sponsor Public Health Domain at IHEPublic Health Domain at IHEPublic 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 ReportingIBM-sponsored
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.
PHDSC / HRSA EXPERT PANEL IN ELECTRONIC DATA EXCHANGES