In the last post we looked at existing permit information and workflows to better understand what data to develop for the project and how that data will support existing workflows. Understanding the data and how it is used is a great start, but now we need to consider the role of software in the project and post-project period. So, in this post we will look at using software design to support the initial development tasks and existing workflows, but also how design can be used to accommodate new uses of the data in the future.

Fortunately, we have been working on the software design for a couple of years now with FetchEH, so we already have a strong foundation in place. I won’t take a deep dive into what FetchEH is here, but the 50k foot overview is that FetchEH is designed specifically to serve onsite wastewater workflows, is built on top of modern GIS, database and web technologies, and is already being used by Health Departments to support data collection and mapping workflows.

While FetchEH is actively used and provides a solid foundation for the project, we still needed to conduct a deep review of the existing data model and mapping/collection process for this project. Part of the review process included pilot mapping approximately 50 permits with a variety of system types and ages. The initial mapping and data collection revealed that there were still modifications required before we could scale beyond the pilot.

Many of the modifications involved increasing detail, or further segmentation of the data, improving a mapping/collection tool or process, and reorganizing how or where data was managed. The objective was to make sure that we develop septic system data in a manner that does not limit its ability to serve existing workflows and potential future use cases. The most challenging part here is forecasting how the data will be used to serve potential future uses because there are no examples to point to.

Much of our knowledge of how a location-based inventory might be used comes from demonstrating possible use cases to environmental health professionals and hearing their feedback, and by our own experience using location-based data and tools.

Even with feedback from environmental health professionals and our experience, it is not possible to predict all future uses of data. There are some things that can help us improve the odds a bit and they involve effective design. Our previous experience tells us that location-based data in general will enable specific capabilities, like asking questions about the inventory, visualizing system data on a map, performing analysis and gaining new insights about the inventory.

So, while we can’t forecast all potential future uses of the data, we can design the software to serve the known and likely capabilities of the data. Our job then is to focus on making sure FetchEH has the framework and flexibility in place to support location-based septic system data, and the tools that unlock the capabilities of these data to serve a wide range of possible use cases.

Because FetchEH is built on top of GIS, and because it is focused specifically on onsite wastewater workflows and data, it is already designed to leverage the capabilities of a location-based septic system inventory. In this way, we have broadly bracketed potential future uses based on the capabilities of the data and supporting software. That is not to say we have everything covered, but we have done our best to design with the future in mind.

Now that we understand more about the data, how it will be developed and how we can support its use, we will scale the pilot to map approximately 300 additional systems before scaling to full production mapping. In the next post we will look at the concept of representing location.