1 / 57

Countermeasure and Response Administration Working Group Webinar

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

deanna-vega
Download Presentation

Countermeasure and Response Administration Working Group Webinar

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related