1. Collaborative Development of Data Extracts and Reports to Support Notifiable Disease Reporting and Analysis Lesliann Helmus, MS Office of Epidemiology Virginia Department of Health August 25, 2008

2. Topic Outline Reports module in NBS Collaboratively developed datamarts and reports Lessons learned about collaboration

3. Reports Included in NBS System comes with basic reports and datamarts to support analysis –Counts –Line and bar graphs –Map –Line lists Address disease statistics, process monitoring, error checking State developed reports and datamarts address additional user needs Incorporated into base system functionality or Shared directly between states Helpful to have SAS and SQL skills to create new reports

4. Development of NBS Datamarts and Reports in Virginia Additional data marts and reports are proposed in Virginia as needs are identified –Prioritized with input from Office of Epi Workgroup, health district users and technical team Development process is iterative –Initial specifications prepared by business and technical teams –Technical team clarifies issues with users as they develop –Tested by central office and district users in NBS Training sys –Refinements made by technical team based on feedback Some used only in Va, some shared directly with other states, some incorporated into NBS by team at CDC Include QA reports, process management reports, disease counts, and data marts to support them

5. Core Case Information Datamart Developed in Virginia Epidemiologists’ challenges with NBS data structure –Collects and/or stores similar information in multiple locations (e.g., age/DOB, onset/cough onset) –Stores the same information in different tables, depending on the condition (e.g., BMIRD, hepatitis…) –stores multiple values for some fields (e.g., race) –collects multiple measures (e.g., test results) Users want a single values they can rely on We want to ensure consistency in data use so that people “get the same answer” Public_health_case_fact (PHCF) table didn’t have all the needed fields

6. Core Case Information Datamart Created in Virginia Provides one point of access for data common to all cases, including demographic and Virginia-defined fields, plus select data from associated Observations and Notifications Used for most statistical reports and data extracts “Flattened” data structure simplifies data use Has “summary” fields – New fields that combine or are based on data from a number of other fields Has pivoted information – Multiple rows of associated data have been transformed into multiple columns to show values from all responses

7. Core Case Information Datamart - Age in Years - Age is collected as a number and unit (e.g., 5 days or 18 months or 54 years) “Age in Years” provides the “best” value for patient age and presents it in years for ease of use Determined by: 1. Difference between DOB and Event Date, or 2. Age at Onset (if DOB is null), or 3. Age Reported (if Age Onset is null) Converted from units entered to years and rounded down to whole years

8. Core Case Information Datamart - Race - Race is collected as a “Check all that apply” list of census race categories “Race” pivots and summarizes data to provide a single value for patient’s race, regardless of how many race values are in the master patient record Determination: –Single Race Category (White, Black, Asian, American Indian or Alaska Native, or Native Hawaiian or Other Pacific Islander) or –Mixed (if multiple races checked, excluding Unknown) or –Unknown or –NULL Also show each race checked (i.e., Race1, Race2, Race3, Race4) We show 4 because there were no cases with >3 races. Most reporting sources only collect one race

9. Core Case Information Datamart - Case Count - No easy way for users to tell which cases are included in official counts so there was variation in statistics they generated “Case Count” field indicates whether a case is counted in official statistics or not Ensures that local and state generated stats match and are consistent with MMWR counts 1=counted, 0=not counted Determination: –Case Status = Confirmed or Probable, and –Notification was approved and sent to and received by CDC For conditions reportable in Virginia but not nationally, we have developed case definitions and we submit notifications so that they will have a case count of 1 and will be included in case counts

10. Core Case Information Datamart Collaborative Process Need was recognized by central office users interacting with district users Office of Epidemiology “NEDSS Workgroup” identified problems and proposed solutions –includes representatives from general communicable disease, immunization, TB, STD, HIV, zoonotic and environmental disease, and the technical team Presented to health district users –NEDSS conference calls held every-other month for feedback and information dissemination –All 314 users invited to participate, usually >70 take part Presented to other NBS states on NUG call Incorporated into NBS by team at CDC

11. One-Page-per-Case Report Developed in Virginia Request for “one page per case” layout for potential rabies exposures Had to be available to users through the NBS reports interface and be transportable to other states –Therefore, needed to be done with SAS programming Formatting presented significant challenge - brainstormed with experienced SAS programmers from other NBS states Received feedback on drafts from requesting user and other users

12. One-Page-per-Case Report Developed in Virginia Work on patient summarized on one page Key demographic information provided at the top Information presented about each injection Information displayed at specified location on page so that user knows where to look for it

13. Documentation Facilitates Use and Transportability Documentation on data elements used in reports and datamarts includes: –field name –interpretation –source

14. Documentation Facilitates Use and Transportability Documentation for each reports provides: –description of report –suggestions for use –criteria for record inclusion –filters used –data elements included

15. Lessons Learned from Collaborative AVR Development Collaboration can reduce duplication of effort, and yield a better product, but collaborative approaches are time intensive With the NBS, closely aligned purposes and objectives mean that we are all focused on the same target Differing state priorities allow states to focus on different projects (but make it more difficult to find collaborators) Shared NBS architecture and vocabulary facilitate collaboration and transportability There is still variation between states

16. Lessons Learned from Collaborative AVR Development There are not good standards for some public health concepts (or else we just haven’t learned where to find them) Involvement of NBS team at CDC provided needed standardization (often developing states couldn’t justify the resource expenditure to generalize the product) Good documentation is essential for re-use of products Processes and authority for decision making are critical