Countermeasure and Response Administration Working Group Webinar

1. Countermeasure and Response Administration Working Group Webinar Webinar Presented December 10, 2008 Jeanne Tropper, MS, MPH jwu0@cdc.gov & CRA Development Team Division of Emergency Preparedness and Response National Center for Public Health Informatics

2. Agenda • Introductions and Purpose • CRA Working and Focus Group Activities to Date • Review and Finalize High Level Requirements for the Six High Priority Areas • Next Steps

3. Purpose of CRA Working Group and Focus Groups • Foundation for All Hazards support near completion • V1.9 and V1.10 will complete the CRA base system under the current contract; thereafter will migrate to open source (OS) environment; closer alignment with OMS and Epi Info ™ • Working Group established to formalize process for prioritizing features, gathering requirements and development of final releases

4. Activities to Date – Working Group • Webinar July 30 • CRA Background and Purpose • Demonstration of selected features of CRA 1.8 • Introduction of high priority areas • Webinar August 13 • Demonstration of additional features of CRA 1.8 • Discussion of high priority areas and requirements • PHIN Conference Meeting August 25 • Established rankings for highest priority areas • Post - PHIN Conference – two meetings • Finalized priorities

5. CRA Topics Ranked by Priority

6. Activities to Date – Focus Groups • Established CRA Focus Groups to gather requirements for each of 6 high priority areas • Each Focus Group met twice over the last two months and established draft requirements

7. Topic One – Group Dispensing (Formerly Head of Household)

8. Group Dispensing Definition • Group Dispensing (formerly Head of Household Dispensing): group of members in a family, work unit, organization, neighborhood or group-living situation receiving countermeasures • All of members of family or present at the Point of Dispensing (POD) • One member collects and dispenses medication to others in group not present at POD • Person picking up medications may or may not receive the medication for themselves

9. Group Dispensing Scenarios Scenario 1 Well individual goes to POD to pick up medication for ill members of their household Scenario 2 Exposed members of a household present to POD for medication Scenario 3 A nursing home administrator picks up medications for all residents

10. Group Dispensing – High Level Requirements • Flexibility to configure data needs for various dispensing methods, i.e., fixed POD, drive-thru POD • Links with other high priority features • Population Health Management • Pre-load demographic data for a group • Alternate Data Entry: • Barcode reading – medication, driver’s license, staff • OCR scanning - paper data entry forms • Ability to enter minimum set of data initially; complete detailed individual information later

11. Group Dispensing Requirements Group Level Data • Capture group name and information • Unique group identifier • Indicate type or category of group: family, office, long-term care facility, emergency response organization, neighborhood • Capture group address and contact information • Location • Address – city, state, zip code • County • Phone number • Ability to self-select group name • Capture medication dispensed to group • Names of medications • Number of medication courses

12. Group Dispensing Requirements Individual Level Data • Define minimum dataset about individuals in group: • Name/Identifier • Follow-up • Track adverse events • Receive future doses of medication • Age or date of birth format (e.g. MM/DD/YY) • Weight if under 90 lbs • Health status – 4 to 5 screening questions

13. Group Dispensing Requirements Individual Level Data, continued • Flexibility to collect additional data as determined by type of event • Ability to collect more detailed screening information if time permits; additional data considerations include: • Contraindications and conditions • Drug allergies, current medications • Symptoms • Ability to collect contact phone and address if different from group information (e.g., when group is an organization) • Ability to enter detailed data information on medications provided for individuals within a group at a later date

14. Group Dispensing LimitationsIndividual Level Data, continued • Model does not appear to apply to injected vaccines • Dispensing through mail out of scope for now; review other work to date • Requires mailing address and receipt confirmation • May not have names up front; may need to record later • May need to track delivery routes against packages

15. Topic Two – Data Exchange

16. Definition of Data Exchange • The secure, reliable, automated transfer of standardized public health data sets between CRA and non-CRA applications

17. Data Exchange Scenarios Scenario 1 Person-level detail collected at a mass immunization POD via CRA is sent to immunization information system (IIS) Scenario 2 Referral message sent to CRA from an outbreak management system for countermeasure administration Scenario 3 Adverse event message from CRA is sent to VAERS

18. Data Exchange – High Level Requirements • Wherever possible, leverage existing messaging specifications • Use standard industry-accepted data formats • Use PHINMS 2.8 as transport mechanism; free and well-supported • Priorities for data exchange • Exchange with IIS • Exchange with Surveillance and Outbreak Management Systems • Exchange with VAERS

19. Data Exchange - IIS • Use Implementation Guide for Immunization Data Transactions, Version 2.3.1 of the Health Level Seven (HL7), Standard Protocol Implementation Guide Version 2.2 June 2006 • Includes specifications for 4 messages: • VXQ (Query for Vaccination Record) • VXR (Response to Vaccination Query Returning the Vaccination Record) • VXX (Response to Vaccination Query Returning Multiple PID Matches) • VXU (Unsolicited Vaccination Record Update)

20. Data Exchange - IIS, continued • Bi-directional exchange of individual-level records between IIS and CRA systems at all jurisdictional levels, as appropriate • Include demographic information and detail on immunization (e.g., lot number, site where administered, person who administered, countermeasure administered) • Exchange may extend beyond vaccines to other prophylaxes or treatments depending on IIS capabilities to support all-hazards events

21. Data Exchange -Surveillance Systems • Receive referrals from an outbreak management system for countermeasures to be administered • Send individual countermeasures administered records to an outbreak management system; contacts in OM System • Ability to send/receive to other surveillance-related systems, as appropriate

22. Data Exchange with VAERS • Transfer adverse event and patient demographic data VAERS • Support bi-directional messaging between VAERS and CRA

23. Topic Three – Population Health Management

24. Population Health Management Definition • The ability to manage health effects on the affected population for all-hazards threats by: • Identifying at-risk populations based on the scenario • Determining appropriate interventions • Reaching at-risk populations with appropriate interventions • Monitoring response and adjusting interventions

25. Population Health Management Scenarios Scenario 1 An incoming flight to an Airport is quarantined because a passenger has suspected case of avian influenza Scenario 2 First responders at all volunteer fire companies within a state expected to receive a smallpox vaccination; fire chief wants to know the rate of vaccination Scenario 3 In an aerosolized anthrax even a population is targeted, such as a neighborhood down wind, to receive prophylaxis to mitigate the spread of disease

26. Population Health Management – High Level Requirements • Flexibility to configure different types of data loads and reports • Data load may miss people in the group; need way to associate walk-ins • Need to define groups free-form or by pre-defining • Ability to purge, i.e., anticipated outbreak or event does not occur or affect targeted population

27. Population Health Management – High Level Requirements, continued • Linkages to AVR for reporting needs • Data Exchange linkages to Surveillance/Outbreak Management systems to support community transmission-breaking strategies tied to mortality surveillance • Data Exchange with Epi Info™ so that Pan Flu data can be transferred between the two • Recognize and manage duplicates • Merge duplicates • Delete duplicate record

28. Data Requirements – Population-based Data Loads • Provides multiple types of denominator data: • The entire population • Those who received the countermeasure • Those who received the countermeasure and experienced adverse events/contracted the disease/died • Those who got ill whether or not the countermeasure was received • Targeted - capture healthcare workers for a hospital • Broad - capture all licensed healthcare workers • Capture specific group of interest, i.e., line listings from school, campers at a boy scout event, staffers and vaccinators for an event

29. Data Requirements – Population-based Data Loads, continued • Load data include: • Identifier for load – logistical tag to identify group being loaded • Date of load • Number of records loaded • Group category • Associated event or outbreak

30. Data Requirements – Population-based Data Loads • Individual data may include: • Name of individual • Link to group • Occupation • Address • Phone • DOB • Contraindications/health status • Medication history, including immunizations • History of adverse reactions to medications • Exposure to outbreak source

31. Population Health Management Reports • Report by geographic area • Report patient-level data by patient address • Report how many of expected and preloaded patients attended POD • For a population report: • Total number in population • Number who attended POD • Number who received prophylaxis/treatment • Number who did not and reason why • Number who became sick, whether vaccinated or not

32. Topic Four – Analysis, Visualization and Reporting (AVR)

33. AVR Definition • AVR transforms data into useful information in three ways: • Analysis for research and guidance • Visualization for a quick synopsis of event • Reporting for operational support and management decisions

34. AVR Scenarios Scenario 1 Analysis required for patients with adverse events occurring in a specific jurisdiction to assess countermeasure efficacy or countermeasure delivery issues Scenario 2 Visualization of a project area map displaying clinic sites with hover over capability to allow presentation of name and number of countermeasures administered for a specified date range Scenario 3 Query countermeasure administrations based on user specified selection including the word ‘flu’ and excluding countermeasures with the word ‘mist’ in the name

35. AVR – High Level Requirements • Require flexibility in providing query criteria for reports • Reports to verify data exchange • Reports to verify synchronization between jurisdictional deployment of instances of CRA • Data Exchange with Epi-Info, SAS, SPSS to support analysis needs • Data Exchange with ESRI GIS tools, Google Maps to support visualization needs • Data Exchange with WEB EOC type applications to provide prophylaxis status of first responders

36. AVR – High Level Requirements, continued • Potential links: • Population Health Management - reports that use denominator data loaded to support Population Health Management • Jurisdictional Deployment with ability to create a reporting template, or analysis algorithm and use it as a format across clinics • Data Exchange to support operational reports

37. AVR Requirements - Analysis • Extracts for analysis tools, e.g., Epi Info™, SAS, SPSS, other • Data filtering option for data export that supports “and”, “or”, and “not” functionality • Ad hoc data query functions

38. AVR Requirements - Visualization • Support or link to application with GIS capability, linear graphs, bar charts, pie charts • Use map capability to determine pockets of need, i.e., areas requiring better immunization coverage • Provide common operating picture (COP) at state level to show status of vaccinations as part of an exercise across the state, e.g. different counties, dispensing locations, clinics, etc. • Support ability to drill down on state level report

39. AVR Requirements – Reports • Need operational reports for various levels of use • Determine expected population and track progress over time toward 100% coverage • Identify people receiving a particular countermeasure for follow-up, i.e., recall, adverse event, need for more medication

40. Topic Five – Jurisdiction Deployment

41. Jurisdiction Deployment - Definition • The ability to deploy CRA at a state, local or clinic level and support secure synchronization of data across multiple instances regardless of mode of operation

42. Jurisdiction Deployment – Scenarios • Scenario 1 • CRA is deployed offline in a POD with no internet connectivity; system is pre-loaded with event, countermeasure and aggregate group information with automated updates; data is synchronize with the state each day • Scenario 2 • CRA web-based deployment is used in a state; PODS across the state access the state level CRA via the internet; the state provides summary data to the CDC • Scenario 3 • CRA web-based deployment is used in a municipality; PODS across the municipality access CRA over the internet; municipality receives setup data from the state and sends data to the state

43. Jurisdictional Deployment – High Level Requirements • Local Deployment of CRA to support off-line collection of CRA data when internet connectivity is not available • Support rapid, effective collection of data by local and state entities • Ability to send locally collected data to central storage at local or state level to be aggregated with rest of the data • Support definition and sharing of a core dataset • Support local or jurisdictional customizable data layer on top of the core dataset (user-defined fields and capability can support this)

44. Jurisdictional Deployment – High Level Requirements, continued • Support strong security measures to protect data in all deployment models • Data should be protected in the database, on laptops, on the network • Laptop and network protection is managed by states • Potential links with other high-priority topics: • Alternate data entry for local collection of data with subsequent upload or synchronization • Data Exchange for synchronizing data • Record de-duplication

45. Jurisdiction Deployment Requirements • Deployment models • Web-based CRA at the state level - highest priority at this time • CRA at POD level where internet connectivity is not available – next priority ability to synchronize to state level

46. Jurisdiction Deployment - Synchronization Models and Requirements • Synchronization at all levels is required, for example: • Configuration data • Person-level data • Synchronization includes addition of new records, updates to existing records, and deletion (may be soft deletion) of incorrect data • Templates for reports or analysis algorithms may be included in setup information • Synchronization of setup or configuration data must be easy and efficient; with state security restrictions, IT may be involved in software upgrades • POD level CRA instances may be transitory and not exist beyond an event

47. Jurisdiction Deployment – Event Specific Set-up Requirements • Need ability to define minimum core dataset that is event-specific • Priority groupings may or may not be specific to type of event • Specific items (e.g., site of injection, lot number, etc.) may be tracked for one event but not another • Support local and state data element standardization • Integration with master patient index to reduce duplication and simplify data synchronization of patient data

48. Topic Six – Alternate Data Entry

49. Alternate Data Entry Definition • The ability to support alternate data entry modes such as barcodes, form scanning, Tablet PCs, or handheld devices (such as PDAs) to increase timeliness, efficiency and/or accuracy of data capture

50. Alternate Data Entry Scenarios Scenario 1 During a drive-thru flu vaccination clinic, an individual’s demographic data is captured by scanning their driver’s license Scenario 2 Data entry forms collected at a mass prophylaxis clinic are scanned and the form fields are captured in CRA data fields Scenario 3 Minimal demographic and screening data is collected during a community dispensing event via PDA and the data collected is merged into CRA