DLAD Tech and Analysis Teams

 

While it is important not to duplicate efforts, it is also important to ensure the solutions we build are fit for purpose.  While there are a number of initiatives to build Community and Health Information Exchanges and referral networks, we believe the rapid proliferation of platforms trying to meet a wide set of requirements and legal constraints (HIPAA, FERPA, etc) makes them unsuitable for our immediate implementation.  

Strategically, our analysis indicates that building a purpose-built prototype while the systems landscape focuses down to a few key platforms might give us the opportunity to learn the depth and breadth of requirements for tracking disaster recovery.

If you are looking for an impactful set of creative opportunities at the intersection of data, community, and climate impact mitigation, you have come to the right place.

An Introduction to Technical Considerations

Here’s a set of slides offering a lot of context on the technical considerations on this page as well as a set of initial technical and design questions to spark the team’s collaboration.

Solution requirements

Data dictionary 

• Balancing efficiency and privacy, while being comprehensive enough to be impactful.  

Use cases to be addressed in the first few versions of our solution

1. Self registration
2. Supported registration – canvassers helping people register
3. Importing of data from partners – typically spreadsheets
4. Paper-based data collection and input options if power and mobile networks are down.
5. Support navigation help – recovery tracking, case management, data sharing to other partners to support progressive engagement
6. Duplication of Benefits calculations for FEMA
7. Updating data on existing records with the ability to build more complete data over time using progressive engagement techniques.
8. Individual ROI settings (Release of Information) to allow vetted relief organizations to see who needs help but give each user control of their data.
9. Needs assessment analysis for individuals and macro across the community
10. Recovery status reporting, met and still existing needs
11. Partner coordination and collaboration
    1. Which organizations will be trained and ready to register people? When?
    2. Each survivor can record their own case numbers from the various partners – FEMA, Red Cross, DCMP to allow easy recall and to let disaster case managers to see what support is already in process.

The Technology Stack and a Prototype

A DLAD prototype has been built in Google forms, try it here: Register as Disaster Affected

Unfortunately, Google forms may not work for the scale of problems we will face in the days ahead.  A hosted stack like Google Open Health Stack or AWS Amplify might begin to meet our needs, but this decision will be early, crucial work for the technology team.

To build a robust, secure solution worthy of our community we believe that we need to bring expertise into the design and build process for any solution capable of handling future disasters.  To give an idea of the scale of demands on the system:

• Almeda fire – 2,800 structures – roughly 2,400 homes at 2.44 each ~5,860 people (the best data set we have seen is 800 names)
• Cascadia tsunami – estimated 27,600 displaced households or ~66,000 people

This is an open source project so feel free to use this in your community as a basis for your own solution.

Skills Required to Avoid the Next Data Disaster 

Expertise required in the coming days

• Product/Development managers to define requirements and manage the project to build our solutions
• Data architects to build and extend an efficient and comprehensive data structure 
• Technical architects to design and improve the technology required to support our solutions
• Application developers to build front and back end tool sets for collecting, analyzing, and reporting on data
• Socialization liaisons to collaborate with all recovery partners, especially the COAD, in order to be able to quickly deploy the solution in case of a disaster. This will require broad outreach to all possible partners to prevent other agencies from doing a similar data gathering. This will require partnering with- likely- Rogue Food Unites as the boots on the ground immediate center of CBO services.

Nb. The skills required of this initiative will change over time as the solution is built and stabilizes and as disaster recovery unfolds. The technical skills will be required in the beginning but may only come into play later if changes are needed and response to a particular disaster situation.

Data Structure

• Proposed data structure based on the Open Referral human services data structure.
• See a more detailed ERD in Lucid Chart and data dictionary.

Proposed Development Roadmap

	2023		2024				2025
	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
Data		–	–	–
Hosting		–
App versions	v0			v1				v2
Analysis				–	–	–

Version features

v0 – Prototype in Google Forms. Only the most basic fields from the data dictionary are stored in one table.  Updates requested by another Google Form and manually updated.

v1 – online application development stack, relational database with data dictionary extended based on HHS and disaster best practices, data validation at entry, user rights management, entry forms for self, supported, and file imports, reporting via Excel BI connections, mobile Release of Information notification and approval process.

v2 – user and organization management, data dictionary updated, data collections and validation workflow management, audit trail for updates, MyRecovery dashboard for individuals, MyCommunity dashboard (for organizations), rules-based ROI and permissions granting loops, analysis toolset for deduping, prompting data collectors to complete data. 

Nb. we assume no API integrations with existing systems for a variety of technical and legal reasons.

Related Initiatives Locally and Nationally

While DLAD seeks the efficiency and effectiveness of close collaboration with existing projects, to meet its goals, we must remain focused on speed and trust.  Our current analysis suggests that while CIE platforms like UniteUs and VisionLink might prove useful in the long run, the immediate needs for community ownership, control of partners and data required for trust, and ease of UI and data structure changes make a stand alone solution most desirable. This decision should be evaluated by the Development and Technical teams annually to align with any emerging community solution that could meet our requirements.

Local

• Reliance
• Rogue Hub
• Continuum of Care for houseless people

State

• Legislation – HB 3303 and HB 4150 – CIE funding

National

• Open Referral documentation
• UniteUs and VisionLink
• ServicePoint and Homeless Information Management
• The FEMA approved service
• NIH study on improving data collection post disasters (damage assessment)

International

• EU Disaster Data Collection – quite high level
• UN Development Program – lessons on collecting data post disaster (damage assessment)
• World Bank – Global Facility for Disaster Reduction and Recovery (GFDRR) (GIS and damage assessment) – Volunteer Technology Communities

Organizations We Aspire To Engage in the Tech Team

• Organizations whose expertise and community commitments have them engaged in conversations around how they might support DLAD
  • Rogue Credit Union
  • People’s Bank of Commerce
  • Lithia
  • Asante
  • Providence
  • H&D
  • Code Zeal
  • Amazon Web Services, Google