Public Health Data Standards Consortium

Public Health Data Standards Consortium http://www.phdsc.org

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.


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


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


HRSA Project officers

Ms. Jessica TownsendDr. Michael Millman


DAY 1December 5, 2006


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


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


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


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.


DAY 2December 6, 2006


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


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


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?


SESSION 4: Roadmap for Public Health Functional Requirements Standards:



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






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.


A Functional Requirement Standard: National Efforts and User Role

Dr. Anna OrlovaPHDSC


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

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


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


BaseStd

LOINC

HITSP

IHE XDS-MS

IHE XDS-I

BaseStd

DICOMHCPCS

CPT

CCCICD 9/10


HL7 V3

HL7 V2.5SNOMED-CT

LOINC UCUM

HAVE


URL

SNOMED-CT

Document-basedScenario


ComponentAnonymize


BaseStdISODTS/25237

HIPAADICOM


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

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


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.


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


Immunization

Lead and Environmental Epidemiology

Injury Control

School Health

Chronic Care


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


Immunization

Lead Registry

Injury Control

School Health

Chronic Care


Genetic Disorder

WIC


Immunization

EPSDT

Injury Control

School Health

Chronic Care


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


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.

https://mail.jhsph.edu/exchweb/bin/redir.asp?URL=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


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


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


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

Provider 1

Provider 2

Provider 3

Provider 4

Provider X


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


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



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]


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]



Order Placer

Acquisition Modality

ImageManager

ImageArchive

DSS/ Order Filler

Patient Update [RAD-12]


Storage Commitment

[CARD-3]

Evidence Creator Modality PS in Progress [CARD-1]

Modality PS Completed [RAD-7]

Instance Availability Notification [RAD-49]



Placer Order Management [RAD-2] Filler Order Management [RAD-3]

ADT

Query Images [RAD-14] Retrieve Images/Evidence [CARD-4]

Image Display


Storage Commitment

[CARD-3]


Procedure Updated [RAD-13]


Performed Procedure

Step Manager




Order Placer

Acquisition Modality

ImageManager

ImageArchive

DSS/ Order Filler

Patient Update [RAD-12]


Storage Commitment

[CARD-3]

Evidence Creator Modality PS in Progress [CARD-1]

Modality PS Completed [RAD-7]

Instance Availability Notification [RAD-49]


ADT Order Placer

Register J.Doe

AcquisitionModality

Placer OrderManagement –New [RAD-2]

Patient Reconciliation

Department System Scheduler/Order Filler

Schedule Procedure


Modality Procedure Step Completed [RAD-7]J.Doe ->

J.Smith

Patient Update/Merge [RAD-12]

Modality Procedure Step Completed [RAD-7]

PatientRegistration [RAD-1]


Modality Procedure Step In Progress [CARD-1]


Perform Acquisition

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


ADT Order Placer

Register J.Doe

AcquisitionModality

Placer OrderManagement –New [RAD-2]

Patient Reconciliation

Department System Scheduler/Order Filler

Schedule Procedure


Modality Procedure Step Completed [RAD-7]J.Doe ->

J.Smith


Modality Procedure Step Completed [RAD-7]

PatientRegistration [RAD-1]




Perform Acquisition



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


Lab Results Document Content


Scanned Documents Format of the Document ContentImaging Information


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


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


BaseStd

LOINC

HITSP

IHE XDS-MS

IHE XDS-I

BaseStd

DICOMHCPCS

CPT

CCCICD 9/10


HL7 V3

HL7 V2.5SNOMED-CT

LOINC UCUM

HAVE


URL

SNOMED-CT

Document-basedScenario


ComponentAnonymize


BaseStdISODTS/25237

HIPAADICOM


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




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






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






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.


Public Health Data Standards Consortium

Documents

Transcript of Public Health Data Standards Consortium