http://openfda.ventera.com/web/#/
##Summary: This web-based application enables users to search and filter adverse reactions related to the intake of specific drugs based off publicly-available FDA Drug Incident Reports. The goal is to both help people understand what adverse reactions may occur and arm them with information to ask the right questions to their medical providers. The application consumes a public API of drug interactions and provides a robust means of searching one or more drugs, while displaying potential reactions in an easy-to-understand collection of graphics, tables and references to NIH definitions of drugs and reactions.
![marketing] (https://github.com/akulasainath/18frepo/blob/master/18F%20Evidence/Marketing%20One-Pager.jpg)
For a closer look at this Marketing 1-pager, click here.
##About Ventera Ventera Corporation is a small business, delivering high-value technology outcomes to both the private sector and the federal government for nearly two decades. Two of our largest federal clients—the USDA Food and Nutrition Service and the Department of Homeland Security—have embraced our Agile Scrum methodology as a proven means of ensuring valuable, user-centric solutions.
##Project Approach When the RFQ was released, the selected Product Manager, Swati Khandewale, had the authority to make both budget and implementation decisions regarding the prototype.
The Product Owner (PO) team used a lean approach when initially presented with the RFQ prompt. The first step in that approach involved defining both a problem hypothesis and a customer hypothesis. Assumptions surrounding those hypotheses were then validated or invalidated through analysis of data provided in OpenFDA APIs and conversations with potential users. Our team then determined a goal for the prototype and concluded a high-level user story:
As a concerned patient, family member, or friend, I want access to information in past FDA Drug Incident Reports so that I am aware of patient drug reactions.
Personas were identified to ensure that user stories developed for the prototype addressed specific user needs. Detailed user stories and tasks were created in a Product Backlog. Each user story was prioritized to ensure that the most impactful items were completed first.
The team decided Kanban was a more appropriate Agile methodology for a project with the time constraint (Ventera usually employs a Scrum approach). Kanban allowed Ventera to deliver value quickly while minimizing waste. Frequent user story prioritization ensured that every feature added to the prototype provided value.
A co-located cross-disciplinary Technical Team was assembled for implementation purposes. The discovery phase allowed the Technical Team to determine the application’s architecture and technical stack and also provided the PO team with the opportunity to ensure that the Technical Team was aligned with project goals and objectives. The PO team elaborated the highest priority user stories for the initial iteration. A designer worked with both teams to create wireframes for the initial implementation approach. A live Design Style Guide was created in order to remain in sync with the code.
The Ventera team applied many Agile best practices from a technical perspective.
-
Agile Tenet #1: Value individuals and interactions over processes and tools: During implementation, Ventera employed an iterative approach using daily standup meetings and application demos to collect feedback from the PO team for each iteration. The team’s key area of focus was to achieve a “quick win” from the first iteration.
-
Agile Tenet #2: Value working software over comprehensive documentation. The team set and successfully achieved a key goal by delivering a minimally viable product (MVP) within 12 hours of discovery.
-
Agile Tenet #3: Value customer collaboration over contract negotiation: A user survey was created to solicit and incorporate feedback from potential users outside of the team in order to full understand what people need.
-
Agile Tenet #4: Value responding to change over following a plan: Human-centered design techniques were employed during the design and development of the prototype. The team conducted a usability survey and ensured that feedback from the survey, along with demo feedback and feedback from a Heuristics Evaluation was added to the GitHub Product Backlog as new user stories and prioritized by the PO team for subsequent iterations. This continuous feedback loop allowed the team to ensure that user needs drove scope.
-
Test-driven approach: Major focus was placed on quality assurance, automated testing, and continuous monitoring.
-
Jenkins was used for continuous integration for our test and production builds, allowing multiple builds a day, ensuring that delivery wasn’t slowed by infrequent integration. Jenkin’s clones the source code directly from GitHub and then performs the necessary build tasks and deployment procedures
-
Our source code and Karma test classes are analyzed with SonarQube Javascript metrics, as part of every Jenkins build/deployment to the Test environment
-
The team also employed unit and integration testing techniques to ensure that implemented functionality met acceptance criteria. A Karma-Jasmine testing framework was used to unit test implemented functionality.
-
The automated test framework includes Selenium WebDriver, Maven, and TestNG.
-
CloudAware, CloudWatch, and Modit were used in a 3-pronged approach to continuous monitoring.
-
The prototype was evaluated for responsive design on multiple platforms using an emulator tool.
-
GitHub was used for Configuration Management.
-
##Open Source Applications: This prototype utilizes multiple open source frontend and backend technologies, including 10+ modern technologies that had the first stable release in the past 5 years. All technology used to create the prototype is openly licensed and free of charge:
For additional description of each tool, see the Technical Stack Description.
##Infrastructure as a Service: This prototype is deployed using Amazon Web Services (AWS) Infrastructure as a Service for compute capacity in the cloud. The following are all AWS technologies that were used:
-
AWS EC2 Server Instances running Ubuntu
-
AWS EC2 Elastic Load Balancers and [] (http://aws.amazon.com/autoscaling/) Auto Scaling Groups
##Deployment Process
- In order to run our application, an HTTP web server must be installed on your system. Download and installation instructions, per your specific environment, can be found at http://httpd.apache.org/download.cgi#apache24.
a) For our local deployment we used Apache HTTP 2.4 (http://httpd.apache.org/docs/2.4/).
b) For Windows, Apache 2.4 binaries VC10 at http://www.apachelounge.com/download/ is recommended for use.
c) Download your version of Apache to the C:\ directory and unzip to the same location. If you do not download and unzip to C:\, please be sure to update the ServerRoot within your httpd.conf located in \Apache24\conf.
d) Of course, other web server installations can be used, allowing for versatility across many environments. For example, NPM package manager provides a simple zero-configuration command-line http server.
- npm install http-server -g
-
Clone the repository at https://github.com/akulasainath/18frepo.git, using the desired branch (Release branch).
a) The repository can also be download directly from any internet browser:
-
Move the entire /18FDemo/web directory of the cloned repository to the /htdocs directory (Apache), or the default configured directory, of your HTTP web server installation directory.
-
Start the HTTP web server. Apache instructions can be found at http://httpd.apache.org/docs/2.4/invoking.html.
-
If deployed correctly using the default Apache configuration settings, the application should be available at: http://localhost:80/web/
##Docker Instructions For detailed instructions for deploying from a Docker Container, click here.
##Contact Information
Chris Ford
EVP, Partner
Ventera Corporation
703-442-5220