Sektors | Klinik-Finder - Psychiatric Care Coverage Finder
Scope
Klinik-Finder(Sektors) is a public-facing search tool backed by a geospatial database and a full suite of internal data-management tooling. The scope of the project spanned:
A public search experience - fast, address-level lookup with an interactive map, designed to be trivially simple for a non-technical user.
A layered data model capable of expressing coverage at multiple levels of granularity, from broad areas down to individual streets.
A geospatial backend for storing and querying area boundaries and address points.
An admin tooling suite for turning unstructured source material into clean, structured, searchable data.
Performance engineering to keep search fast as the underlying dataset grows large.
The application was architected to expand its coverage area incrementally, adding new regions over time without any structural change to the search experience.
Problem
The core problem is a real-world administrative mapping: every address falls under the responsibility of a specific facility, but that mapping is not readily accessible to the people who need it. Making it accessible turned out to be surprisingly hard for several reasons:
Coverage is defined at multiple granularities. Some facilities are responsible for whole localities, others split a single locality - or even a single postal area - down to the street level.
Administrative boundaries don't align with postal boundaries. A postal area can straddle an administrative border, so any naive "classify by postal-code prefix" approach misassigns border locations.
Source data is unstructured. The underlying coverage information originates from documents rather than clean datasets, and includes ambiguous and inconsistent entries.
Scale. A complete address-level catalogue runs to very large row counts, at which point naive search becomes too slow to use interactively.
The challenge was to deliver something effortless for the end user while being precise and fast enough to be genuinely trustworthy.
Solution
Klinik-Finder solves this with a carefully layered data model, a geospatial database, a resolution strategy that handles multi-granularity coverage cleanly, and a set of internal tools that make maintaining the data practical.
A search that resolves the most specific rule
The public search accepts partial input - postal code, locality, or street - and returns results as the user types. Under the hood, coverage is resolved by a "most specific rule wins" strategy: a street-level rule takes precedence over a broader area rule, which takes precedence over the widest match. This is what lets the same system answer both "which facility covers this whole town?" and "which facility covers this particular street?" with a single query path.
Results are grouped by type and rendered as an autocomplete dropdown, each tagged with the responsible facility, and shown on an interactive map with color-coded pins and area-boundary overlays.
Boundary-aware classification
Rather than deriving a location's administrative region from its postal-code prefix - the approach that breaks at borders - the system derives it from the responsible facility, which is unambiguously tied to a region. This makes border locations classify correctly by design, with no manual exception handling, and keeps the model self-maintaining as new facilities are added.
Tooling as a first-class part of the product
Because the source material is unstructured, a large part of the solution is the internal tooling that converts it into clean data:
A review-and-import workbench with per-row validation, duplicate detection, bulk operations, and safe deletion.
Batch resolution that turns a plain list of localities into structured, import-ready rows by resolving each against a trusted postal-data source.
An address-gathering tool that pulls real address points for a set of areas from an open mapping source.
An interactive geometry tool for loading, previewing, filtering, and publishing area-boundary data, including a report of any requested areas missing from the source.
Utility tools for extracting a region's full set of areas, comparing sets to find coverage gaps, and performing safe, confirmation-gated bulk maintenance.
Key Features
Public experience
Fluid, prefix-based search - partial postal codes, house numbers, street names, and localities all match as you type, rather than requiring exact, complete input.
Region-first filtering to scope results and keep the experience fast and relevant as coverage grows.
Interactive map with color-coded facility pins, area-boundary overlays, hover tooltips, and quick "jump to" controls.
Clean, purpose-appropriate UI - uncluttered and trustworthy, in keeping with the sensitivity of the subject.
Data tooling
A spreadsheet-style import workbench with validation and safe bulk operations.
Batch locality-to-area resolution against trusted postal data.
Address-point gathering from an open mapping source with progress and coverage reporting.
Interactive area-boundary loading, filtering, gap-reporting, and publishing.
Set-based utilities for extracting, comparing, and maintaining coverage data.
Integrity by design
Access-gated write and delete operations, with privileged credentials used only server-side.
Destructive operations are dry-run-first - they report exactly what would change before anything is touched, and require explicit confirmation.
Uploads are idempotent, so re-running an import updates existing records rather than creating duplicates.
Input validation and strict format checks throughout.
Performance Engineering
Search over a large address catalogue is where the most interesting engineering lives:
Index-backed substring search so "search-as-you-type" matching uses an index rather than scanning the full dataset.
Precomputed, indexed classification - anything that would otherwise be recalculated on every query is computed once at write time, stored, and indexed, turning expensive per-query work into a fast lookup.
Locale-aware normalisation so that the many valid spellings of a name all match consistently.
Query design tuned for real workloads, ensuring the database uses the right index as the primary driver even when multiple filters are applied.
A dedicated bulk-load path for large datasets, kept separate from interactive, incremental updates.
Together these keep search responsive - millisecond-range at the database level - even as the dataset grows very large.
Design Decisions Worth Highlighting
Separating authoritative rules from bulk reference data. Keeping the small, clean source-of-truth separate from the large reference catalogue keeps the model maintainable while still enabling the most granular lookups.
Deriving classification from a trusted anchor rather than from brittle heuristics, which eliminates an entire class of edge-case errors and keeps the system self-maintaining.
Compute-once, store-indexed. Moving repeated work from query time to write time is the single biggest lever for keeping the app fast at scale.
Treating tooling as product. Converting messy source material into clean, structured data is most of the real work, so the tools that do it were built with the same care as the user-facing product.
What Could Be Improved
Honest next steps and known limitations:
True geometric assignment. The system resolves coverage through layered rules today. The most robust model would define each facility's catchment as a boundary polygon and assign a location by geometric containment, falling back to rules only where boundaries are unavailable. The geospatial foundation to support this is already in place.
Automated source ingestion. Data currently starts from unstructured source material processed through the admin tools; structured-import or recognition pipelines could reduce the manual transcription step.
An explicable trail. Logging why a location resolved to a given facility - which rule matched and which were excluded - would add transparency, valuable in a sensitive domain.
Automated freshness checks. Underlying data changes over time; scheduled validation against authoritative sources would keep the dataset trustworthy.
Accessibility and localisation passes, plus automated test coverage around the core resolution and import logic, to harden the most critical paths as the project grows.
Outcome
Klinik-Finder is a useful public tool backed by a non-trivial data model, a geospatial database, and a complete suite of internal tooling to build and maintain the underlying data. It takes an obscure, document-bound administrative system and turns it into an instant, address-level answer to a question that matters to people at a difficult time.
Key technical themes: full-stack TypeScript, geospatial data (PostGIS, GeoJSON, Leaflet), search performance at scale, third-party data integration, data-pipeline tooling.