1. Anne Elixhauser Mamatha Pancholi Jenny Schnaier
Input Your Data – Output Your Website: A Web-Based Tool for Quality and Utilization Reporting
Anne Elixhauser
Mamatha Pancholi
Jenny Schnaier
The EQUIP project team at AHRQ:
Anne Elixhauser, PhD
Senior Research Scientist
Mamatha Pancholi, MS
Project Officer – Quality Indicators
Jenny Schnaier, MA
Project Officer – HCUP
September 2008

2. Leveraging the Expertise of Four Organizations
Development Team
Leveraging the Expertise of Four Organizations
Here is the entire development team
We’re leveraging the experience and expertise of four organizations:
AHRQ – overall vision
Battle – QI expertise
SSS – HCUPnet expertise
TR – Web interface expertise
Convert existing
WinQI Wizard
Produce QIs
Adapt PHC mapping tool
Test the tool
Produce HCUPnet-like utilization queries
Test the tool
Lead web development
and presentation
Coordinate design
efforts
Test the tool

3. Outline The Efficiency and Quality Improvement Portal What is EQUIP?
Why is it important?
Who is the audience?
How will EQUIP work?
When will it be deployed?
Today, I’ll be telling you about a new tool that we’re developing that we refer to as EQuIP: the Efficiency and Quality Improvement Portal.
I’ll walk you through the basics of:
What is EQuIP?
Why is it important?
Who is the audience?
How will EQuIP work?
When will it be deployed?
Please feel free to ask questions throughout my talk if anything is unclear.
We should have time at the end for additional questions, as well.
We are very interested in hearing your reactions, thoughts, suggestions.

4. THE BIG QUESTION WAS: IS THIS FEASIBLE
WHAT: The Concept
A WEB-BASED TOOL THAT PROVIDES LOCAL INFORMATION ON HEALTH CARE USE, COSTS, VOLUME, AND QUALITY
AHRQ creates and distributes software programs to generate web-based query system
Local organizations use programs to host a web-based query system
Local users access the web-based query system to obtain health care information
So, let me lead you through the basic concept.
Our intent is to develop a web-based tool that will allow users to report information about health care use, costs, volume, and quality at the local level.
The project was presented and approved as part of the Value Portfolio that supports the CVEs.
AHRQ would provide all the software needed to generate the web-based query system – including, the programs that would generate the website itself. And the website would then be maintained by the local organization.
After this website is created by the “host organization,” local users could access the website to obtain health care information.
The aim is to provide local information on health care utilization, quality, volume and costs.
We believe that this type of product could be of tremendous value to many different audiences, but we needed to tackle the big question of “Is this feasible?” For this, we needed a “proof of concept” – and, I’m happy to report that we have proved it’s possible. I will go into more details about how we approached creating EQuIP in a bit, but before I do that I want to talk a little bit more about the rationale for why this kind of tool is needed. ?
THE BIG QUESTION WAS: IS THIS FEASIBLE
Project presented and approved as part of Value Portfolio Supports CVEs

5. CONSUMERS NEED HEALTH CARE INFORMATION TO MAKE INFORMED CHOICES
WHY: Rationale
CONSUMERS NEED HEALTH CARE INFORMATION
TO MAKE INFORMED CHOICES
“What hospitals in my area perform heart surgery?”
“How many bypass procedures are performed at hospital x versus hospital y?”
“What is the quality of care for cardiac procedures at hospitals in my area?”
“I don’t have insurance, how much should I expect to pay?”
We all know that consumers lack basic information about health care that they need to make informed choices.
It is disturbing that, in most cases, the average health care consumer (like my mother or Aunt Mary) can obtain answers to basic questions such as,
“My husband needs to schedule a heart surgery. I want to know what area hospitals perform heart surgery and how many procedures do they perform annually.”
Or, questions like, “What is the general quality of care for cardiac procedures at my area hospitals?”
Or, the critical question of “I don’ have health insurance, how much should I expect to pay?”
Currently, there is very limited healthcare data available to answer such questions.
CURRENTLY, THERE IS VERY LIMITED HEALTH CARE DATA AVAILABLE TO ANSWER SUCH QUESTIONS

6. Rationale State/local organizations have resource limitations
Unable to develop comprehensive reporting system
AHRQ can provide support for these organizations
While consumers need access to health care information, state and local organizations have resource limitations that mean they’re unable to develop a comprehensive system to provide this kind of data.
The idea is that AHRQ could provide support to these organizations by providing them with some of the tools needed to create an on-line tool that outputs health care information.
And by using a single tool with the same approach and methods, the information will be comparable across areas.

7. DHHS & AHRQ Missions DEPARTMENT OF HEALTH AND HUMAN SERVICES MISSION
Protecting the health of all Americans and providing essential human services, especially for those who are least able to help themselves.
THE AGENCY FOR HEALTHCARE RESEARCH AND QUALITY MISSION
Improving the quality, safety, efficiency, and effectiveness of health care for all Americans.
The EQuIP project supports the mission of the Department and the Agency,
which is to protect and improve the health of all Americans.
The intent of this tool is to empower individuals to make informed health care decisions.

8. From Data to Information to Action
Hospital discharge data are already being collected
Hospital discharge data can generate valuable healthcare information
Consumers can use this information to make decisions
The beauty of this tool is that it relies on data that are already being collected. There is no need for expensive data collection efforts.
As long as hospitals are billing for services and generating billing records, hospital administrative data (discharge data) will be collected.
This discharge data can generate valuable health care information about the utilization, cost, and quality of care in hospitals.
Consumers should have the opportunity to factor this information into their healthcare decisions.
From Data to Information to Action

9. WHO: Two User Groups – Host and End User
END USERS: PEOPLE USING THE WEBSITE
Consumers
Health Planners
Policy Makers
Media
Data Analysts/Researchers
Multiple audiences but Consumers are the principal audience
HOST: ORGANIZATION BUILDING THE WEBSITE
State and local data organizations
Chartered Value Exchanges
Hospitals
Anyone with access to provider-level data
Let me now move on to who the audience is for this tool. There are actually many different audiences, but we think of them as two categories of users:
the host organization and 2) the end users.
Host users are the organizations with the data.
These can be state gov’t data organizations, hospital associations, CVEs, individual hospitals
End users are people who need information. We see multiple audiences but consumers are the principal audience.
However, health planners and other public health folks and policy makers are a key group we think will find this information useful.
The media are another key audiences.
And data analysts and researchers can get valuable information as well.

10. HOW: The Making of EQUIP...
Iterative rapid development
Storyboard
EQUIP code
Now the question of HOW we plan on making EQuIP happen. This slide shows a simplified diagram of the steps we are going through.
First, we needed a storyboard. This step involved getting a number of team members and experts together to draw out what EQuIP would look like.
It’s a rough visual representation of how the tool would function – similar to a storyboard for an animation.
This is the “thinking and brainstorming” phase of the project. It’s essential that the storyboard be well thought out as it feeds the next phase of the project which involves creating the software programs.
For software development, we used a technique common in the tech world called the “iterative agile development” or “rapid application development.”
We use an iterative build process with fairly short turnaround periods.
Each time a build is complete the group reviews the progress, tests the functionality, and make suggestions for improvement.
And these suggestions are incorporated into the next build cycle.
In this model, the product goes through constant review and update – and, evolves into a polished, final tool.
We plan to alpha test the entire tool in October with a limited number of users and then beta test the tool in late January with a larger group of users.
The alpha and beta testers will include potential state/local host organizations as well as end users.
The final product that we create will be a set of “EQuIP Code.”
Continuous “Alpha” Testing
Beta Test: Larger number of testers

11. Local EQUIP Website EQUIP Code
End users will access the EQUIP website to run queries about healthcare utilization, cost, and quality for local hospitals and areas
We will then distribute the EQuIP code to organizations that have access to hospital discharge data.
The host organization will implement the code and load their own discharge data to create a local EQuIP website on their own servers.
End users will be able to access the EQuIP website from any computer that has internet access to view information on their local health care markets/hospitals.
EQUIP code will be distributed to organizations that have access to hospital discharge data
Host organization will implement code and load discharge data to create local EQUIP website on their own servers

12. General Considerations as Development Proceeds
USING A SMART DEVELOPMENT AND DESIGN APPROACH
Efficient development
Adapt existing programs to feed into the EQUIP system
Minimal burden
Develop web system based on most commonly used programs and software platforms
Ensure methods can be understood by wide range of host users
Customizable features
Modular
Customizable user interface
Comprehensibility
Ensure information adheres to standards for conveying statistics to public
Documentation
Document methods throughout for host and end users
Accuracy
Iterative testing of results
Throughout the development process we are employing a smart development and design approach.
We wanted an efficient development process, so it was important to adapt existing tools into the system as much as possible...
We did not have time to build everything from scratch, nor did we think it was efficient to work that way. I’ll discuss these existing tools in a moment.
We wanted to minimize burden on our host organizations.
Many of them face significant resource limitations.
So, we developed our code based on software programs that commonly used (obviating the need for the host user to purchase additional software) and ensure that the methods we applied could be understood by a wide range of host users.
Microsoft .net runtime (free)
Microsoft SQL Server Express (free). Other versions of SQL Server 2005 should also work.
The WinQI /Site builder application
An HTML/text editor (free- this may or may not be necessary)
A web server (Microsoft bundles IIS free with server operating systems, Apache is free for all platforms)
We wanted to make it customizable so that hosts could choose what they wanted to present and make the website look like their own (colors, graphics, logos).
Comprehensibility: We consulted with experts to make sure that the information could be easily understood.
We are documenting our methods throughout the project for both the host and end users
Lastly, we are doing a lot of iterative accuracy testing of results.

13. Customizable Features
Modular
User can choose which pieces to implement
Generate user-defined reports
Create maps of various measures
Drill down on specific issues by patient and area characteristics
Customizable Interface
Users can insert their logo and organization name
Our intent is to make this tool modular – meaning that the host user can select if they want to adopt all three paths or only specific paths.

14. The Model: HCUPnet Quick, Free Access to Data
As I mentioned, we are modeling EQuIP off of existing products – such as HCUPnet. HCUPnet is a free, on-line querying system that provides access to the HCUP nationwide data, as well as state-level data for those states that choose to participate.
We don’t present any information at the hospital-level in HCUPnet. The key benefit of EQuIP is the ability to access to local and hospital-level data.

15. AHRQ Quality Indicators
Another important AHRQ tool that we’re incorporating into EQuIP are the AHRQ Quality Indicators
The QIs provide information on inpatient quality and potential safety problems.
In addition, the QIs use hospital information to provide information on potentially preventable hospital admissions.

16. EQUIP = HCUPnet + QI + More
QIs
EQuIP is a tool that is borrowing from other successful tools while adding new features.
From HCUPnet, we are developing the utilization query path, output tables, interface, as well as definitions, help, and other features.
From the QIs, we are adapting the WinQI tool (a Windows-based data input tool), the AHRQ QI measures, the reporting template, and a mapping tool.
Query Paths, Output Tables, Interface, Help and Definitions
WinQI Tool, AHRQ QI Measures, Reporting Template, Mapping Tool

17. A Brief Technical Overview
EQUIP Site Builder (“Wizard”):
Moves host user through the process
Raw data from user
Programs that load data, map values, transform data, and
build data cubes
Page writers
Graphics
generators
(for Utilization and QI data)
Website query interface seen by end user
This slide shows a technical overview of EQuIP:
Host users (the organization with administrative data, e.g., HCUP partners, CVEs, individual hospitals) would supply their own raw data.
A Configuration builder (or Wizard) would lead the host user through a step-by-step process of generating everything they need to host their own website based on their data.
There would be a series of programs that would load their data, map values in uniform way, transform it into a form needed by subsequent programs, and then build the data cubes for the QIs and the utilization statistics (which would be accessed in the query steps).
An SQL Server database would store:
Meta-data (descriptions of the data), e.g., DRG versions, source/year of census data
Transformed data for QIs and utilization statistics
Data cubes
The system would supply whatever census data are required for computing population-based rates. It would also provide comparison data (e.g. national and regional statistics) and all labels (e.g., labels for ICD codes, regions, QIs).
The system would include page writers and graphics generators for the QIs and utilization statistics.
It would also include the components of the web system – page writers for context and navigation, script writers and cascading style sheets so there would be a uniform look to the website.
(Context=user-configurable options, parameters and settings, e.g., adding in their logo and org’n name)
(Script writers=we are looking into ways of efficiently generating the output webpages; script writers are programs that write script that will get included in many pages, rather than writing each page individually)
The last section depicts what the end user will see – the person who will access the website – the HTML code for verbal and numeric information and the JPGs for graphics.
Navigation and Formats will provide a consistent look and feel across the website.
HTML and .JPGs for QIs and Utilization information
SQL Server Database stores: Meta-data, transformed data, and data cubes
Web System
Context and
navigation
page writers
Script writers
& cascading
style sheet
writers
Census data
Comparison data
Labels
Navigation
Formats

18. EQUIP Paths THREE PATHS UTILIZATION: HEALTH CONDITIONS AND PROCEURES
View information on patient conditions across hospitals, for a specific hospital, or across geographic areas
RATES: HEALTH CONDITIONS
AND PROCEDURES
View statistics on the rates of hospitalizations for specific health conditions and procedures for geographic areas
The current version of the EQuIP tool has three distinct paths:
Path 1: Utilization of Health Conditions and Procedures
View information on patient conditions across hospitals, for a specific hospital, or across geographic areas
Path 2: Rates of Health Conditions and Procedures
View statistics on the rates of hospitalizations for specific health conditions and procedures for geographic areas, like ZIP codes or counties
Path 3: Quality Indicators of Hospitals and Areas
View measures of quality for hospitals or areas based on the AHRQ Quality Indicators
QUALITY INDICATORS FOR HOSPITALS AND AREAS
View measures of quality for hospitals or areas based on the AHRQ Quality Indicators

19. Three Paths: Example Questions They Will Answer
UTILIZATION: HEALTH
CONDITIONS AND PROCEURES
QUALITY INDICATORS FOR HOSPITALS AND AREAS
RATES: HEALTH CONDITIONS
AND PROCEDURES
How many C-sections were performed at area hospitals?
What was the average charge?
How long do patients usually stay in this hospital for C-sections?
What is the volume of CABG in this area?
What is the rate of pneumonia hospitalizations in this region?
What is the rate of blood transfusions in the state?
How does the death rate for heart attack patients compare across four hospitals close to my home?
What is the rate of obstetric tearing after vaginal delivery in two hospitals close to my home?
This slide shows examples of what types of questions can be answered by each path:
Path 1: Utilization of Health Conditions and Procedures
(read questions from slide)
Path 2: Rates of Health Conditions and Procedures
Path 3: Quality Indicators of Hospitals and Areas

20. A Peek at EQUIP – How will it work?
The host user (e.g., local/state organization, an individual hospital) will download the AHRQ EQuIP Tool and generate a website
The end user (e.g., health consumers, analysts) will access the website created by the host user to obtain health care data
Example screen shots follow...

21. A Peek at EQUIP – A Working Draft What the Host Sees
the EQUIP Wizard
This tool is the existing AHRQ Quality Indicators Wizard
Is being expanded to build EQUIP
Import Data Wizard – initial screen
EQUIP Site Builder

22. Host User EQuIP Tool: Select File
Select input file
On this screen the host user selects the input file – their raw data file.

23. Host User EQuIP Tool: Load and Map Data
Select options for loading and mapping data
This file stores all of the mappings for future use
Then the host select options for loading data. This file stores all of the mappings so that the use does not have to repeat mappings each time a new file is loaded.

24. Host User EQuIP Tool: Map Data
Map input file variables to variables used by software
On this screen the user maps variables in the input file to the variable names required by the software.

25. Host User EQuIP Tool: Variable Summary
Summary of variables
Just to check everything worked OK, the wizard provides a summary of the variables – like a proc print in SAS

26. Host User EQuIP Tool: Errors Checking
Scan file and report errors
The system scans the file and prepares a report to pinpoint errors.

27. Host User EQuIP Tool: Crosswalk
Map the values from the input data to standard values required by EQUIP
Then the user goes through a process of mapping values for each variable to values required by EQUIP.

28. Host User EQuIP Tool: SQL Server
Data are loaded into an SQL Server
The data are then loaded into an SQL Server

29. Host User EQUIP Tool: Summary Report
And a summary report is generated to verify what happened – number of records, and warnings that might need attention.

30. Host User EQUIP Tool: Data Cubes
Create data cubes
Finally the system creates the data cubes which will then be accessed to generate the output pages for the website.

31. End User Website Interface
EQUIP Site Builder (“Wizard”):
Moves host user through the process
FORM: Which parts of EQUIP does the host want to create?
Raw data from user
Programs that load data, map values, transform data, and
build data cubes
Page writers
Graphics
generators
(for Utilization and QI data)
Website query interface seen by end user
After the data cubes are generated, the host user will be presented with a form.
The form will ask the host user what parts of EQuIP he/she would like to create.
The user can choose to create just the utilization pages, quality pages, or both.
HTML, JPG graphics, and Navigation will be created for the selected pages.
Next let’s look at what the end user will see 
SQL Server Database stores: Meta-data, transformed data, and data cubes
HTML and .JPGs for QIs and Utilization information
Context and
navigation
page writers
Script writers
& cascading
style sheet
writers
Census data
Comparison data
Labels
Navigation
Formats

32. A Peek at EQUIP – A Working Draft What the End User Sees
Select 1 of 3 Paths:
UTILIZATION
RATES
QUALITY INDICATORS
Depending on what parts of EQuIP the host user wants to create, a set of pages will be generated.
Now here is a peek at the working draft of what the EQuIP website looks like to the end user as of our current build
This is the home page. From the home page, a user can select one of the three paths. A Utilization Path, Rates Path, or QI Path.
Right now the Utilization Path is furtherest along in development, so I will show you an example of how the end user could navigate this path.
By clicking on the Utilization link, the user is taken to the next page.

33. Utilization Path: Select Health Condition
Select to view data by service line or by health condition/procedure (DRG)
Allows easy access to the data through “view data now” feature
On this page, the user is able to view data by service line or health condition (DRG), though we’ll be adding other ways of looking at the data.
If the user wants to access data now, there is a button at the bottom of the page that they can click...so they would get overall stats for all patients (e.g., the entire state.
or, if they would like to proceed to view data by hospital, they can click this button....I will show you what happens if they choose to view data by hospital.

34. Utilization Path: Select Hospital or Area
Select a specific hospital or an area
Allows easy access to the data through “view data now” feature
Allows download to Microsoft Excel of summary tables
On this page, users are then given the option of selecting a specific hospital or all hospitals within a health service area.
Users can also download Excel spreadsheets of all summary tables.

35. Utilization Path: Data by DRG
Drill down for more information on a specific condition/procedure
Sort data by any of these columns
This is a screen shot of what data by DRG looks like. We are in the process of simplifying this table by removing some columns (grayed out here), but this is the general look.
The first column presents the DRGs and the remaining column presents outcomes information for each DRG, such as the number of discharges, the length of stay, the hospital charges, etc.
You can resort the table by clicking on the column header (e.g., this is sorted by frequency of cases, but you can also sort by mean charges, etc.)
By clicking on a specific DRG, the user can see detailed patient and payer characteristics….

36. Utilization Path: Drill Down to a Specific DRG
Detailed patient and payer characteristics for newborn hospital stays
In this example, we clicked on the first DRG “Newborn” and we can see that there were about 77,500 newborn stays in this database that are nearly even split between baby girls and baby boys. The hospital charges for baby boys were about $6,700 versus about $6,200 for baby girls (perhaps due to circumcisions?)...

37. Utilization Path: Data for a Specific Hospital
This is a screen shot of what information for a specific hospital will look like. This is for Palisades Medical Center and it shows overall statistics, but users will be able to get details by individual conditions and procedures.

38. Utilization Path: Data for Hospitals in a Geographic Area
Hospitals grouped by Hospital Service Area (Dartmouth Atlas)
And, information for all hospitals within a geographic area.

39. Quality Path
Another AHRQ tool that we’re incorporating into EQuIP are the AHRQ Quality Indicators.

40. Quality Path: Consumer Report versus Detailed Statistics
Two options: Interested in (1) the report for consumers, or (2) detailed quality statistics?
Allows user to download detailed data to Excel
The EQuIP QI path is not as fully developed as the Utilization Path, but here is the general concept.
Users will be able to select between two options:
(1) Report for consumers (this is the only functioning option right now)
(2) Detailed statistics (we will be building this next )
The Report for Consumers is the more user-friendly, lay person option of viewing quality information.
This is blank text box that covers up some text I didn’t want to show in the final screen shot – it is white text on white background.

41. Quality Path: Health Topics
Select one of ten quality health care topics:
Heart conditions
Brain and nervous system
Childbirth
Hip replacement and hip fracture
Operations for cancer of the esophagus and pancreas
Other surgeries
Other health conditions
Medical complications of patients having an operation
Medical complications of all patients
Medical care for children
Users select 1 of 10 health topics of interest.
These topics group QIs into areas that have been tested and found to be understandable by lay users.

42. Quality Path: Indicators
Select all indicators within a topic or specific indicators that comprise the topic
Users select to see all indicators within a topic or a specific indicator that is part of that topic.

43. Quality Path: Hospitals
Select a specific hospital or up to four hospitals in an area
Allows easy access to the data through “view data now” feature
Allows download to Microsoft Excel of summary tables
Users then select a specific hospital or up to four hospitals in an area.

44. Quality Path: Comparing QI Measures Across Four Hospitals
This is an example of what the final output could look like (walk through the output).
All the text is taken from the QI Reporting Template developed by Shoshanna Sofaer. The text has been audience-tested.
“Indicator 1” etc. will be replaced by the specific names of individual indicators.

45. Preventable Hospitalization Costs Mapping Tool
PHC mapping tool will be incorporated into EQUIP.
Better understand geographical patterns of hospital admission rates.
Calculate potential cost savings if admission rates are reduced. 45 45

46. Output: Excel Spreadsheet with Cost Savings Estimate
Potential cost savings if number of admissions were reduced by specified percentage
QI Name
County name, mean cost of admission for indicator, number of cases, and total cost 46 46

47. The Last Path: Utilization Rates Path
Utilization and QI Paths are under active development
A third path, the Rates Path, is being designed
A third path, the Utilization Rates Path, is being designed at this time.

48. WHEN: Timeline – 9 months from Concept to Product
Concept First Build Continuous Builds Beta Test
Incremental Builds
APRIL 2008 JULY JULY - DEC JANUARY 2009
Incremental build throughout Summer and Fall using an iterative rapid application development methodology
TARGET COMPLETION DATE OF PHASE 1: JANUARY 30, 2009
So, when is this all going to happen?
We’re in the process right now. The concept was initiated in April We produced our first build three months later in July Currently, we’re on our third build and we will continue producing refined builds through the end of this year. By the end of January, the beta version of this tool will be completed.

49. Challenges Aggressive timeline
Variety of users will want to use the system
Different system capabilities
Different resource availability
System needs to have minimum requirements
Need to keep the cost of implementation low
Limited nature of static model versus dynamic model
There are several challenges that we have faced and expect to continue to face, the largest of which is the aggressive timeline. Typically, based on consultation with technical experts, this type of software development can take years – just gathering the requirements and specifications can take a year. Our goal is to build the entire product in 9 months. And, while this will be challenging, we know we can accomplish this goal.
Another challenge is the variety of users who want to accommodate.
Lastly, to ensure our success in completing development by January 2009, we opted to use a static model rather than a dynamic model.
This means the EQUIP builder produces static HTML pages which are then accessed by the website.
This is not a dynamic site like HCUPnet which generates output tables on the fly.

50. Phase 1 versus Subsequent Phases
EQUIP is an evolving tool – the current version is a prototype
Phase 1
3 Paths
Utilization
Rates
Quality
Mapping capability
National and regional benchmarks
Static design
Subsequent Phases
Additional Paths
Hospital Compare
HCAHPS
Evaluate other data sources
Provide links to other resources
Dynamic design
Consider adding other federal data sources
Many more ideas...will also solicit user suggestions
This is a summary of where we are now and what our thoughts are for future development:
In the next phase, we plan incorporate information from Hospital Compare and HCAHPS
We plan to evaluate other data sources such as BRFSS and all-claims data which are now developing in a number of states.
WRT to all-claims data, several states have started collecting all claims – not just in-hospital claims. They are getting information on office visits, pharmacy claims, basically all settings and types of care that would get reimbursed through insurance. But the use of these data is just about where we were 20 years ago with inpatient data – basic utilization and cost information.
If we can build tools that these states can apply to their new claims data systems, this would jumpstart the use of the data and would facilitate development of standard data systems across the states.
We also plan to provide links to other resources, such as how to address high rates of preventable hospitalizations.
We will also evaluate what it will mean to move toward a dynamic design.
And we will be soliciting ideas from users to guide further development.

51. What makes EQUIP unique?
EMPOWERS organizations and consumers to use data to make informed decisions
Provides organizations with the ability to create/host their own website and upload their own data
Enables local organizations to do their own reporting using a standard, validated method
Allows users to draw together multiple data sources that provide information at the local level

52. Questions?
Comments?
Suggestions?