NACCHO’s Model Practices Program honors and recognizes outstanding local health practices from across the nation and shares and promotes these practices among local health departments (LHDs). Model and promising practices cut across all areas of local public health, including, but not limited to, community health, environmental health, emergency preparedness, infrastructure, governmental public health, and chronic disease.
Once practices are designated as model or promising, they are stored in the Model Practices Database so all LHDs can benefit from them. NACCHO began accepting Model Practices submissions in 2003. Since then, NACCHO has placed numerous model and promising practices in the searchable online Model Practice Database with more added each year.
Since 2003, the collection and review of submissions had largely been a manual process. LHD’s entered data through a web form which was ultimately downloaded into either a Microsoft Excel spreadsheet or Microsoft Access database. Submissions went through a two-stage content review and collaboration process, often involving four or more reviewers whose actions were coordinated by NACCHO personnel and tracked manually through a series of excel spreadsheets. Due to growth of the program, this labor-intensive process was deemed to be unsustainable and Fig Leaf Software was called in to design and implement a workflow system that would automate the submission, review, collaboration, and publication cycle.
Here’s a flow chart that we created as part of our specification process that models the review cycle:
Workflow process model (click to enlarge)
Figure 1: 3-Tier Architecture
A 3-tiered architecture segments your app into three distinct service layers:
- The User-Interface
In the pre-smartphone days, organizations could settle on creating a single front-end that only supported desktop browsers. With the proliferation of mobile devices of all shapes, sizes, and capabilities, corporate IT must now consider developing multiple front-ends for their apps. At an absolute minimum, line-of-business apps should support desktop and tablet with reduced functionality available for phones. This requirement frequently requires that multiple front-end apps be developed in parallel, each accessing a common REST-based webservices api implemented at the business intelligence tier.We chose to develop the front-end using Sencha’s frameworks – Ext JS 4 and Sencha Touch for the following reasons:
- Sencha Toolkits use a well-defined client-side MVC architecture, helping to ensure coding standards among developer team members thereby leading to reduced future maintenance costs.
- Both frameworks have good tooling (Sencha Architect and Sencha Cmd)
- Consistency in the Desktop and Phone API’s means that we can rapidly develop a mobile phone GUI by repurposing the data model classes from the desktop GUI.
- Flexibility to upgrade in the future to the recently released Ext JS 5, which will enable us to support both desktop and tablet GUI’s from a single codebase.
- Ext JS 4 has full backwards compatibility with IE8 – an important consideration when we evaluated NACCHO’s target audience of municipal health departments.
- The Business Intelligence Tier
- The Database Tier
NACCHO’s corporate standard is Microsoft SQL Server. We designed an efficient, normalized 20-table schema with referential integrity rules that enforce valid data input. Due to the dynamic nature of the application, MongoDB might have actually been a better choice from a development perspective – but since it wasn’t a corporate standard and we had already chosen .NET as the middleware, we went with “old reliable.” We use Microsoft Full Text indexing to drive the front-end keyword search.
Organizing Around Perspectives
NACCHO Model Practices has four different user roles:
- Casual browsers who want to search and retrieve Practices.
- Applicants who are submitting Practices for review
- Internal Reviewers on the NACCHO staff who parcel out Practices for review
- External Reviewers who review and comment on Practices as well as collaborate on forming an opinion as to whether a submission is a Model Practice, Promising Practice, or Neither
- Administrators who perform an initial review of submitted practices, create the submission form, create and run ad-hoc reports, and manage the overall review cycle.
To address the very different roles and responsibilities of the stakeholders, we organized the application around a series of “Perspectives”
The Browser Perspective
The Browser Perspective, as illustrated by Figure 2, enables users to easily apply filter criteria to search through NACCHO’s Model Practice database. The Ext JS 4 data grid automatically downloads records in the background as the user scrolls, reusing DOM elements on-the-fly to keep memory overhead at manageable levels. Search filters are applied automatically after a user stops typing in a field.
Figure 2: The Browse Perspective running in Satan’s favorite browser (IE 8)
Users can resize and rearrange grid columns. In addition, all of the sections of the layout can be expanded or collapsed in order to maximize available space. These settings persist between a user’s sessions, enabling them to create a personalized interface that only shows the information that they find to be helpful.
The Applicant Perspective
The Applicant Perspective, as illustrated in Figure 3, enables logged-in users to edit, save, and submit a Model Practice for review. Ext JS’ rich form field widgets, customizable validation, and flexible layouts enable us to dynamically assemble the form at runtime based on instructions that are read from the server. We also implemented a “Print” feature that redraws the form in a printer-friendly format with hard page-breaks that separate each section.
Figure 3: The Applicant Perspective. Yes, this works in IE 8 too!
In order to facilitate the editing of large blocks of text, we created an Ext JS extension that integrates the best-in-class TinyMCE 4 WYSIWYG editor and added a previous/next buttons at the bottom of the screen to help users navigate through the different tabbed-based sections.
The Administrator Perspective
The Administrator Perspective, depicted in figure 4, uses roles-based security to restrict access to administrator/reviewer functionality by role.
“Super Admins”, of course, have full run of the system but are primarily responsible for the following tasks:
- Reviewing the initial submissions and assigning them to an “internal reviewer”, a subject matter expert within NACCHO, who reads through the practice and decides whether it has been properly categorized.
- Designing forms
- Creating and running reports
- Auditing the review cycle
- Managing accounts
Figure 4: Assigning an initial reviewer
Using the Form Builder Perspective
Since NACCHO’s survey form changes from year-to-year, Fig Leaf Software designed the Model Practices application to enable non-technical admins to customize their forms without involving I.T. Form fields can be grouped into tab panels and we support collecting data via text input fields, wysiwyg editor (TinyMCE 4), select boxes, checkboxes, and radio buttons. Admins can set data validation rules to require input on select fields, restrict text input by word count, and more!
Figure 5: Admins can build custom forms without involving I.T.
We’ve implemented several query-by-example reporting tools into the Model Practices application. Admins can quickly identify the status of practices in workflows and run statistical roll-ups on approved documents. Using Sencha Ext JS 4, we were able to easily present data in a scalable grid and display aggregate statistics in a native web chart. We also developed a custom extension that allows users to export the information in any grid to Microsoft Excel, as illustrated in figure 7.
Figure 7: Executing reports, charting the results, and exporting to Microsoft Excel
In rare cases, query-by-example interfaces might not be sufficient to enable administrators to extract the information that they require. To handle any reporting criteria that might come up in the future, we implemented the query builder, depicted in figure 8, that enables admins to create a dynamic filter for every field on any form. We’ll be posting the Query Builder code to GitHub before the end of the year.
Figure 8: The Query Builder enables admins to create and save custom reports.
The Internal Reviewer Perspective
As illustrated in Figure 9, the Internal Reviewer’s job is to read through the submitted document and assign subject-matter experts (external reviewers) who will grade and judge the responses. If an Internal Reviewer decides that the submission has been incorrectly classified, they can reclassify it forward it back to the Administrator who, in turn, can pass it on to a different internal reviewer. This view uses a drag & drop, searchable grids that facilitate the assigning of external reviewers. We used a third-party extension, Ext.ux.grid.Filterbar, to define the “filter row” depicted in the “Search for Reviewers” grid control.
Figure 9: Internal reviewers read through the submissions and assign them to external reviewers for “grading”
The External Reviewer Perspective
External reviewers are charged with reviewing the application and answering a series of targeted review questions that were defined in the Form Builder perspective. Responses that don’t meet the designated data validation criteria are denoted by a red [X] in the left-side tree control. Once they have completed commenting on applicant responses, they designate the application as being a “Model Practice,” “Promising Practice,” or “Neither.”
Figure 10: Ranking and reviewing applicant responses
The Reconciliation Perspective
If two or more external reviewers disagree as to whether an application is a “Promising Practice” or “Model Practice”, they are directed into the perspective, depicted in figure 11, where each reviewer can see all of the other reviewer’s responses and comments. They can also schedule a conference call from directly within the GUI to take place via VOIP (implemented by integrating the Twilio API) where they can hash out their differences. All external reviewers must ultimately reach consensus as to whether a submission is a “Model Practice”, “Promising Practice”, or “Neither”.
Figure 11: Comparing other reviewer’s responses, scheduling a conversation, using VOIP
Once the external reviewers reach consensus the applicants are notified via email of it’s final disposition and, if rated as a “Model Practice”, or “Promising Practice”, the application becomes accessible to the public on the web site.
Built using Sencha Architect
Sencha Architect, depicted in figure 12, enabled our development team to respond to changes in our customer’s requirements with agility as well as rapidly prototype and visualize new features. Using it’s deep integration with Sencha Cmd made it easy for us to create and post development, testing, and production builds.
Figure 12: Sencha Architect’s visual designer enabled our development team to act with agility.
Futures – Mobile and More!
Model Practice Mobile Prototype
Using Ext JS for the project paid off handsomely when the customer asked us to develop a level-of-effort (LOE) for porting the search perspective over to a mobile-phone form factor. Using Sencha Architect and relying on the REST-based api that we produced during the desktop app development phase allowed us to create a quick proof-of-concept using Sencha’s Touch framework.
Would you like to know more?
Please contact us at email@example.com to find out more about our custom application development services and how we can help you realize your visions of productivity enhancements across your enterprise in a cost-effective manner!