dariaengineering / dcaf_case_management Goto Github PK

Vallejo is a django tool that Mollie found out about at CFA which solves a similar problem (managing a variety of contacts and cases, logging touches with them, and then marking them complete): https://github.com/codeforamerica/vallejo-css-toolkit

(The alternative is whipping up something from scratch, most likely.)

I think this requires a conversation with some django-comfy folks about adapting this to our needs and how much of the core engine and wiring we'd have to replace.

If it IS adaptable to our needs, it's a great head start!

Let's use this as a starting point: https://playbook.cio.gov/designstandards/form-templates/#login-form (s/o Mollie for flagging!)

These models need basic verification tests to ensure that objects save information the way we think they do.

A good best practices primer on what to test in model tests (and testing in general!) is here: https://robots.thoughtbot.com/how-we-test-rails-applications

Scenario: I'm a case manager, and I have made a call to an existing patient which ended in leaving a voicemail, or talking to the patient, or the number no longer working. Should write an integration test confirming that this creates a record of the contact.

When you click that X on the right side of the green 'Signed in successfully' box, the message is supposed to dismiss, but doesn't.

The HTML for this is in app/views/layouts/_messages.html.erb; I suspect it's a JS error, maybe the Bootstrap JS library not being loaded.

Story: As a new contributor to the project, I want an easy way to get up to speed so that I can start helping as quickly as possible.

Possible solution: we need to keep a light weight blog or similar platform where we can note recent accomplishments, such as at the end of each Code for DC hacknight. That way a new contributor can see not only the commit history but non-code accomplishments, such as design activities.

TODO: figure out the norms/process for how this content will be updated and pick a tool, such as the wiki attached to this repository or a hackpad, to use.

Some points we may want to track:
- decisions made
- scrum in post form
- next steps

Users will need different type of reporting tools based on the data collected by case manager. The reports can be either in a dashboard or even in a static report. The dashboard can display number of active cases that are available or that need to be called in queue. They can also sort by demographics/income/zip codes of all the patients in the database.

There should also be an ability to export the data in .csv where they can manipulate the data.

The reports could be run by a individual case manager or at case manager supervisor level. At the individual case manager, they will probably want information that is related to their activity for the night or to help them manage their calls.

labels, milestones etc

document on readme

Nothing fancy, just go into config/routes.rb, figure out what the Devise sign in route is, and make it so that someone going to http://localhost:3000/ will go to the sign in screen.

update the readme with step by step instructions for setting up the site in a development environment.

Populate db/seeds.rb with some sample data that we can use for experimenting in a development environment. Should include:

• A completed case
• A half-finished case
• A fresh case
• An abandoned case

Will work on this with @NerdyGirl537 and @lwaldsc to make sure this is consistent with spreadsheet patterns.

(Gold medal version: FactoryGirl testing fixtures that also match these patterns.)

We need to be able to quickly explain DCAF's workflow to new team members. We'll use the User Flow #5 but need more of a checklist model of things to cover

See http://open.dc.gov/civic.json/ for more information.

Create a view with basic signup information with necessary information from the User model -- nickname to use, email address, set password, etc.

add to readme
policies on forking and merging pull requests

Based on source research in the Google Drive (team members can help with access to this), design a high level user flow to describe the application. Post it to the repository.

--> this issue needs more detail if people are going to pick it up and do it without a lot of introduction.

What happens once the user hits 'Submit pledge'? Things may include:

• finalizing pledge amount
• creating PDF to fax
• faxing PDF
• going back to start screen

Since we're using CircleCI, let's add the appropriate badges to the Readme.

I think we have an open question about what Case Manager / User name data to have in this information, specifically whether to do first name and last name both, or just an all inclusive name.

Background: We set up models with both first and last in #38, and I rolled this back in #49 to allow user objects to save again. (Devise requires that you specifically whitelist non-devise attributes, which in #38 are first_name, last_name, role, and line. We also may need to change pages downwind, such as the sign up page.)

Beyond just the code changes, though, we should figure out what to do about including CM full names.

My own perspective is that DCAF rarely uses full names on the internet or in its current spreadsheet except in cases of board of directors, and I'm (admittedly) gunshy about use of full name, so I'd prefer to use an abbreviated name or nickname.

However, @NerdyGirl537 pointed out that this is would be a barrier to autofilling full name on pledge forms, which is true and also a problem, since part of the goal of this app is to make the rote parts of CMing less time-intensive.

A few sample options of how to proceed:

• Full name only
• Full name as a slightly buried field in a different place than name, so it's not IMMEDIATELY accessible but still accessible via the app (a little extra development, slightly safer).
• Split the baby and do something like 'type in your name to send the pledge', and require a full name there (would require some annoying extra development but safer)

I'm totally open to criticism that I'm being too gunshy on this and that we should roll with first name and last name and it's no big deal, but would like to get the discussion on record to inform a group decision, and have something to use as a signpost in case this pops up again.

cc @lwaldsc @mebates @Kevin-Wei @drownedout @adinneen as immediate stakeholders / people who worked on #38 .

Add basic unit tests for user model to confirm that user records are save-able and stay that way as we develop.

Create a basic form for creating a contact -- see the call modal at https://projects.invisionapp.com/share/6757W6WFJ#/screens/115983265 . Bonus points for putting it in the modal!

A pair of people went thru the Cloud9 local build directions tonight, and some useful feedback we got was that it's helpful to specify what kind of specific server to run, just in case. (Rails stable + Ruby 2.x.) Otherwise, the green 'Run Server' button is unresponsive.

We should add this to Cloud9 directions to avoid frustration and confusion.

We'll need to set up a Patient#create route to create new records of cases.

The minimum version of this is creating a core Patient -- the gold medal version is creating an associated Case at the same time on creation of patient. No need to incorporate other object relationships yet.

Since we've settled on Rails, I think the next major architecture decision we need to make is how to store our data securely and accessibly. DCAF is able to spend some money in order to outsource the security component of this rather than rolling it up from scratch, so cost should be a factor but we shouldn't just take the closest, free-est option and hack that into what we need. (If we have to spend like $25-50 a month for a solution then DCAF can swing that without issue).

My wishlist for this, more or less in order:

• Extremely secure (we are storing very sensitive information, after all)
• Well documented
• Able to provide a separate, distinct account for every case manager
• Has a ruby wrapper

Here are two options for secure-looking data storage that look like they might be a very good fit:

Salesforce Nonprofit edition

http://www.salesforce.org/nonprofit_product/nonprofit-editions-pricing/
This is a lot of firepower but they have a REST API we could use to store and retrieve info without that much of a hassle. They limit us to 10 accounts before we start paying a premium of $30/m per user, so our CM corps is too big to have one SF account per user.
Benefits: Free if we share Salesforce accounts between users, other funds are using Salesforce and have an okay time with it, Salesforce is pretty well documented, seems to be pretty hardcore about security
Drawbacks: Cost-prohibitive for individual user accounts, though we could roll our own with devise

Firebase

http://www.firebase.com
Looks kinda like a separate database-only service, with pretty flexible rules. Seems good about security and encryption, and perusal of the settings page makes it seem like making things inaccessible to certain users after a given amount of time is trivial.
Benefits: There's a ruby wrapper for it, affordable option, security doesn't seem to be an afterthought, googling 'firebase security breach' didn't turn up anything
Drawbacks: Might be tough to figure out how to use -- don't know how good the documentation is

Other stuff I found by googling but don't know anything about, which might be good to investigate:
https://parse.com/
https://fanout.io/

Thanks to the great work of the design team, we've got some designs! So we should adjust the frontend application layout to account for that.

The Invision Prototype, which we should try to match, is here: https://projects.invisionapp.com/share/6757W6WFJ

For purposes of testing, you can go to http://localhost:3000/users/sign_up (the devise login pages).

This ticket has three components:

• Editing the master layout partial in app/views/layouts/application.html.erb to match the top bar in InVision
• Editing app/cases/index.html.erb to account for the change in the application layout (delayed until after sprint 1)
• Gold medal: Where Sarah Caseworker appears in the Invision app, have that populate with either the results of current_user.name if a user is signed in or a link to the sign in page if not.

If I'm a case manager and I make a call, regardless of how it turns out, I want to track that -- how do we represent that in mongo? Is it a new object similar to Note, or is there something inherent in the Note object that we can use?

My inclination is an object similar to Note but could go either way on this. The technical requirement here is that we be able to log timestamps of calls, what came out of them.

Part of the question might be whether or not it's standard practice for a CM to take a note of 'attempted call, no response' for cases that have been going on. If yes, then probably we turn it into a Note and have all call attempts logged as notes for sure -- if not, could go either way.

CMs are logging calls from voicemails with some basic data entry. We'll need a design for this.

Add a screen before a call is placed a patient to record any available information from the voicemail that was left. This is only necessary when a new record is being created because DCAF has no information on the patient.

Add project needs by skillset to the readme. Don't forget about non-technical users such as designers, testers, and copywriters.

What should this thing be called?

Tests for patients controller create and new routes.

Should be located in Patients#new, and be a straightforward web form for patient name, phone, and whether it's cool to leave a voicemail.

What does the very first screen look like for a case manager? How about a positive, grateful welcome and a very easy, no hassle login? What happens if they're a new user? Or if they forgot their password?

To ease onboarding of new members, we should move whatever material we can (i.e. stuff that is appropriate to make public) to the repository from the Google Drive.

CMs should be greeted with some sort of reminder that the work they're doing is important and valued. idk if this takes the form of patient stories, cat pictures, or just a big thumbs up emoji.

Should have step by step instructions to cloning and getting started for mac and pc environments.

In other words: It's my first day at code for dc, I've got the readme open, what do I need to install and set up to be able to run a local server and start wrenching around?

To ensure that the registration system works as expected, we should write an integration test that checks the following:

• There's a sign in link on the main page
• When you log in successfully, a success message displays
• When you are logged in, it displays some information about you (email or name or something) instead of a sign in link, and the bar includes a sign out link
• When you click the sign out link, it displays a sign out message and signs you out

This popped up in #33 from @mebates -- how can we effectively incorporate design reviews into the frontend work we're doing, to take advantage of the immense design talent on this project, and make sure that we're keeping the CMs happy?

Create an end to end integration test of logging in and creating and saving a new patient and case from a call.

Discussions with the data science team have continued and they're yielding some excellent insights and feature requests about how to process patient information. Want to figure out the best way to log them in git -- either a wiki page, separate git issues, or a unified issue backlog.

In several of the models, there are notes of enumeration. These attributes should be added to the respective model files, in consultation with sample DCAF data where appropriate (ask @colinxfleming for this).

Rails documentation on enum is here: http://edgeapi.rubyonrails.org/classes/ActiveRecord/Enum.html

Since we've got a datamodel, let's put it to work and start setting up some CRUD (Create/Read/Update/Destroy) operations!

I think we can make a form at CasesController#edit that'll be equivalent to https://projects.invisionapp.com/share/6757W6WFJ#/screens/115983266 , and then get it to match the designs after we have the controller logic set up and in place.

Let's not stress about some of the more complex functionality like Call Log, Send Pledge, Multiple Funding Sources, or Notes yet. For the time being let's just focus on getting a form up at /cases/:id/edit and retrieving a record.

This is a great resource is one is needed: http://choosealicense.com/

Per https://github.com/aq1018/mongoid-history#usage, Mongoid::History somewhat involved setup requiring:

• Creating a history tracker class
• Creating a history tracker class initializer
• Deliberately making specific object classes trackable
• Tracking the history of specific fields

It also appears that there's an out of the box solution for tracking what user was responsible for changes that we'll want to implement as well; we'll want to verify that https://github.com/tbpro/mongoid_userstamp is still the best practice for this.

To support usability testing and design refinement, build a clickable prototype from current wireframes using Invision - http://www.invisionapp.com/

We need to make a few changes to config/mongoid.yml to connect to the MongoLab instance we've set up in heroku. (This entails setting up a secrets file, either with Dotenv or Figaro, to save production secrets.)

A few models (Note and Case) have comments to add a library called Mongoid::History, so that we can see who made changes over time.

@Kevin-Wei is our local expert on Mongo, but I think this involves using the mongoid-history gem: https://github.com/aq1018/mongoid-history