Operations and recovery

Start a planning task

Open the task menu (Menu on the map, or the left-hand list on other pages) and choose Plan › Start a planning task. Choose Find an underserved area and compare options, or Understand a county’s health needs. That page shows the question, steps and outputs before you enter a tool. The header’s Place and Workspace pickers stay in step with each page’s own selections, and every menu link keeps them.

The first path connects mapped needs and access, existing clinics, and service options. The second leads to a county/community or hospital-specific assessment; the assessment pilot is currently limited to whole Thurston County. A disabled assessment link for another county does not switch you into Thurston silently.

The shared workflow navigation shows your current county and workspace, explains the output, and links to the next relevant action. Workspace, county and supported map context travel in links. A tract selection is removed when you change counties. Saved records still belong to their original workflow; navigation does not automatically merge reports or import analyses.

In service options, search for a clinic by name, choose saved alternatives by name, and tick the supporting evidence and reviewed fields. The option group is your plain-language planning question. Provider forms, identifiers, inventory maintenance and background instructions are secondary controls. Clinic responses are optional: you can use published information and staff research, leaving unsupported facts unknown.

In the directory, enter a name, specialty or service and press Enter or Search county. This searches records beyond the currently loaded map. Source and review filters apply to the displayed results page.

Choose measures with checkboxes in site planning and assessment setup. Categories start collapsed: Health; Population, households and access; Environment and hazards. Open only the categories you need. Selected measures remain visible above the categories and can be removed individually. Select one to five; no Ctrl or Shift is needed.

In site planning, Show selected measures loads your selection. Map layer shades one measure at a time, and clicking a tract shows all selected values. After changing the selection, load it before saving an analysis. Higher diabetes prevalence can identify an area to investigate; it does not automatically identify the best clinic site or count potential patients.

To produce a comparison, create a planning project, save a candidate location, enter a driving threshold and assumptions, and calculate an analysis. Repeat for another location and compare the saved results. Results include tract reference points within or beyond the threshold and road travel estimates. Download the planning report for saved maps, evidence and assumptions. Represented tract population is not an exact count of residents within a drive-time boundary.

Clinic review labels apply to individual details, not to published population measures. Not checked by your team means no current local check is recorded. Checked by your team refers to a dated field-level review. Recheck due means the previous review expired; Needs another review means it needs attention, for example after a source change. None of these labels alone establishes whether a clinic is open. A provider reply is optional: staff can cite dated published evidence.

Operating status and authority

U3b keeps schema 59 and deploys a matching API and export worker with the admitted M1/D5 annex configuration. Read the sealed activation receipt for the active image, container names and loopback port. Historical U4 activation evidence does not establish the status of U3b.

This guide explains the operating procedure; it is not a new deployment, account-change, source-withdrawal or production-restore authorization. Use the controls pinned for the active release and the organization’s approved change process.

Older deploy/operator-manuals pages explicitly describe local rehearsal. Do not treat a local_sink alert, an isolated restore, or a historical rollout command as proof of an operating production service.

Health and readiness checks

Run read-only checks first. A healthy HTTP process does not establish data freshness, complete source coverage, worker progress or database recoverability. Check those separately. Public readiness is intentionally concealed; a public 404 at /readyz is expected.

These are read-only examples for an authorized operator. Set LOOKOUT_ACTIVE_API_PORT, LOOKOUT_ACTIVE_API and LOOKOUT_ACTIVE_WORKER from the sealed activation receipt before running them. They do not print environment secrets or credentials.

curl --fail --silent --show-error https://lookout.soldierdata.us/healthz
curl --fail --silent --show-error "http://127.0.0.1:${LOOKOUT_ACTIVE_API_PORT:?Set from activation receipt}/readyz"
pg_isready
docker inspect --format "{{.Name}} running={{.State.Running}} restarts={{.RestartCount}}" \
  "${LOOKOUT_ACTIVE_API:?Set from activation receipt}" "${LOOKOUT_ACTIVE_WORKER:?Set from activation receipt}"
systemctl show apt-daily-upgrade.timer apt-daily-upgrade.service \
  -p Id -p ActiveState -p SubState -p Result

Release and upgrade procedure

1. Identify the exact application commit, accepted source packages, registry bundles, worker configuration and required test receipts. Build and pin the image; preserve existing work and prior release artifacts.
2. Capture host identities, queue state and current schema. Take a fresh database backup and rehearse restoration in a separate database. Validate remaining capacity and the release-window maintenance policy.
3. Stage read-only packages and a loopback candidate. Verify transferred hashes, source permissions, authenticated data and retained export downloads. Bind the target to the same image, configuration and mounts.
4. Under the current owner-authorized scope, dry-run then ingest the D6 successor and D5 additive registry bundles with exclusive receipts. Retain predecessor versions and grants. Verify new and retained analysis/download reads and dry-run project re-pinning.
5. Complete required browser and application gates. Hash-bind the transition plan, controls, backup, canary receipts and both route variants. Dry-run the exact transition. Current authorization must cover the deployed scope; never fabricate historical C1/C2 acknowledgements.
6. Run the cutover in a persistent operator service: quiesce API writes, require an empty active queue, stop the old worker before starting the new worker, re-pin the project with a reverse receipt, start and check the target, then atomically switch the route.
7. On failure, stop the new API and worker, verify and reverse the project receipt, restart the previous worker and API, and restore the exact prior route bytes. An uncertain project commit requires receipt-based recovery before restoring writes.
8. Verify public health, authenticated browser/data/export behavior and worker stability. Record activation and recovery receipts, preserve the previous release through the rollback window, and ask users to reload open tabs.

Incident triage

1. Record the time, public symptom, request/correlation ID, affected workflow and known release identity. Exclude credentials and private evidence from the incident summary.
2. Check public health, active loopback readiness, proxy state, PostgreSQL connectivity, worker/job state and capacity. Determine whether the problem is routing, process health, access, source freshness, source withdrawal or one export job.
3. Preserve relevant sanitized logs and immutable receipts before a corrective action. Avoid broad docker inspect or environment dumps that expose secrets.
4. Choose the narrow recovery: route rollback for a bad application activation; source review for revoked/stale data; export/job diagnosis for a failed artifact; authorized recovery workflow for database corruption.
5. Verify recovery through the same user-visible path that failed, not only process uptime. Record residual limits, artifact integrity and user communication.

U4 route rollback

Only the r12b rollback control is valid for the completed U4 activation. Earlier revisions can have different guards and targets. This rollback returns the public route to retained U3a on loopback 14224, not to an arbitrary old container.

Before executing, obtain the required owner rollback reference and inspect the active/prior configuration receipts. Run the pinned rollback in a persistent session. Its guards and recovery checks are part of the operation; do not bypass them with a manual route edit.

After rollback, run the prescribed U3a public owner/member canaries with freshly managed credentials if the release credentials were shredded. Verify the expected older frontend and profiles; notify users to reload tabs.

Both staged data trees remain. DOH revocations on the shared U3a tree stay effective. A route rollback neither restores database contents nor reverses a rights decision.

Backup inventory and acceptance

Managed daily backups rehearse schema-59 restoration in an isolated database, verify owners/ACLs and data, and include protected mounted files and pinned images. Hourly operator-host replication verifies hashes before acknowledging the copy. Seven successfully replicated bundles are retained on the server. A whole-host recovery rehearsal and achieved RPO/RTO remain unestablished.

A complete recoverable set includes a consistent database archive, required owners/grants/policies, pinned application/configuration/data identities, external export/artifact inventory and source manifests. Signing secrets require their own protected recovery channel; do not place them in a public backup report.

1. Record the backup owner, timestamp, database/schema version, capture consistency method, archive size/hash and protected storage location.
2. Bind the application, data and configuration pins plus external artifact hashes to that recovery point. Confirm retention/holds and the ability of the recovery operator to retrieve the set.
3. Verify the archive can be read, then perform an isolated restore with a tool that explicitly supports the current schema and PostgreSQL major. A pg_restore listing alone is not recovery proof.
4. Check schema and expected data counts, owners/ACLs/RLS where applicable, artifact completeness, application authorization and a non-delivering worker configuration.
5. Record measured restore duration, the actual recoverable timestamp and cleanup of only the resources created by the rehearsal. Failed or incomplete archives stay failed; select a complete recovery point or escalate.

Recovery procedures and tooling limits

The historical isolated verifier restores a pinned archive into a fresh restricted database and checks selected tables. Its documented proof excludes original ownership/ACLs and external artifacts. The production-restore tool adds catalog/ownership/policy checks for the pre-migration schema-57 rollback across migrations 058/059 on PostgreSQL 16.x.

Those version-specific tools must not be relabeled as an approved current-schema U4 restore. Inspect their supported schema and snapshot versions first. A fresh schema-59 recovery procedure and rehearsal receipt remain an operational acceptance item, not something this documentation task has executed.

For an actual incident, identify a compatible complete recovery point, obtain the incident/change authorization, isolate the destination and disable delivery. Restore and verify it before considering a production switch. Preserve the existing database/artifact state for audit; never overwrite it as an exploratory step.

The reviewed production-restore sequence has separate snapshot, stage, switch, switch-back and rehearse operations. A database name swap is a production mutation requiring all relevant connections and workers to be controlled. Follow that tool’s own versioned manual rather than pasting historical commands from this page.

Incident closure and handoff

• Record root cause or current hypothesis separately from verified facts.
• Capture final health, affected data/artifact checks, release/source identity and residual user impact.
• Confirm candidate/temp resources and credentials are cleaned up, and any intentionally paused timers have an explicit disposition.
• Record corrective work, the responsible role and the evidence needed to close it. Do not label an operational gap fixed because a manual now describes it.

U3b: cited measure exports

This section describes the U3b runtime requirements. The sealed deployment receipt establishes activation; the presence of configuration files or documentation alone does not.

The API and export worker require the same M1 package/configuration and an explicit LOOKOUT_TRACT_ANNEX_CONFIGURATION file using lookout.tract-annex-runtime.v1. The file binds organizationId, projectId, purpose (hazard-mitigation-planning), packageReleaseId, sourceUseIdsByKey (acs_tables, cdc_places, fema_nri) sourceAuthorities and registryBinding. Source use, dataset, release and coverage identities must match the Thurston uses in the M1 serving configuration.

registryBinding has exactly acs_tables, cdc_places and fema_nri entries. Each pins a distinct releaseVersionId ending in -d6, datasetVersionId, observationVersion (3 through 99), and an ISO UTC issuedAt acceptance timestamp. Receipts use this fixed admission timestamp, not the draft creation time. The same bindings must be used when preparing the accepted registry package; defining them does not ingest observations or grant access.

The export authority must explicitly grant the necessary query, internal_export and derive operations and their prerequisites, with current role entitlements. No grant is inferred from a query-only configuration or from an earlier image approval. The root-owned file reader and tighten-only reload rules apply. Revocation is checked during capture, review, enqueue, rendering, publication and download.

Every additional cell also needs a matching admitted release-registry observation, receipt, pins and current download rights. The worker checks these in batches of at most 100. The file-backed source permission check does not replace registry admission. The offline tractAnnexRegistryAdapter projects bound captures into registry bundles and rejects conflicting identities. Source packages retain their independent acceptance. The assembled transformation has a separately recorded engineering acceptance, registry admission and permission checks; existing U4 query-only configuration alone cannot enable exports.

When enabled, Build accepts one geography level and up to five additional M1 measures, optionally with same-county M1 overlap. The saved draft records the choices; changing them requires a new draft and review. Neighboring counties and mixed national/M1 overlap inputs are outside this annex path.

V2 artifacts use standard PDF object streams and ZIP deflate to preserve full citations within the existing 1 MiB artifact ceiling. Legacy V1 output remains unchanged. The API returns a compact capture summary, while full observations and receipts remain in the saved run and annex snapshot.

Reverse re-pin accepts a completed forward receipt even after interrupted completion. Every linked partial receipt must remain available at its recorded absolute path with matching SHA-256, project, release plan, target pins and revision. The chain is bounded; missing, changed, cyclic or unrelated receipts are refused. Retain all partial receipts with the completed release evidence.

A release still requires the prepared data packages, worker mounts, cutover/rollback controls and exact-image acceptance. This manual does not itself authorize a production switch.

Source permission checks use the M1 serving purpose, county-planning; the annex registry uses hazard-mitigation-planning. These are separate bindings, both checked before exports.

Optional D5 storm capture is configured with LOOKOUT_STORM_ANNEX_CONFIGURATION (lookout.storm-annex-runtime.v1) on both API and worker. It pins the reviewed acceptance receipt, package manifest, export partition and annual summary. County-designated and zone-allocated counts remain separate. Narratives and personal fatality details are excluded; missing impacts are not zero.

The U3b assembly scripts under scripts/u3b produce offline review candidates. assemble-combined-runtime.mjs accepts the captured baseline workspace configuration as its final argument and preserves existing permission scope, definitions and boundaries. Entitlement policy revision fields are rebound to the combined policy revision; leaving old revisions causes access to fail. Exact observation-set grants use lookout.runtime-measure-scope.v3 with explicit IDs, versions and dataset/measure/method pins.

The assembled candidate remains pending acceptance until its runtime, registry, retained-export, worker and rollback checks are complete. Packaging and passing tests do not activate the release. Preserve the previous worker, API, registry versions, policy and national data package throughout rollback verification.

Clinic refresh and production monitoring

Weekly Monday 05:00 UTC refresh updates current facts for the admitted CMS cohort, the HRSA snapshot, nine reviewed provider-directory locations and, when available and recent, the complete five-county OSM snapshot. New NPI identities, moved addresses needing geocoding and new directory locations require separate cohort maintenance.

Stale, partial or regressing OSM acquisitions retain the previous OSM layer with its original source date and a warning. Other source failures or unexpected county count changes hold publication. Candidate, target and public checks run before a refresh is accepted, and a failed public check restores the prior route.

Daily 09:00 UTC backups, hourly off-host copies and 15-minute health checks have separate status files and systemd journals. Off-host copying depends on operator-host availability. No external alert delivery or application-level backup encryption is configured. See scripts/operations/README.md for commands, retention, recovery and rollback.

Onboard another county

County onboarding now uses configurable Census boundary acquisition, OSM/HRSA and pinned CMS sources, polygon and freshness checks, cross-source review, immutable release bundles, and runtime county profiles. Supported counties use the same application image without frontend code edits. Real project membership and independently scoped source authority are required.

Generic M1 tract serving and a separately authorized printable HTML evidence annex are available through version-two contracts. This is planning evidence, not a completed HMP or Thurston PDF/Word workflow parity. Accepted analytical source packages are required; automated acquisition covers the supported facility adapters.

The county refresh timer prepares configured counties, holds uncertain changes and retains previous data. Automatic promotion requires an already browser-accepted county/image/profile plus fresh access and HTTP checks. County refresh can follow the verified managed clinic cohort, synchronize the private review journal, and retain a pinned OSM snapshot within its age limit after an acquisition failure. Explicitly pinned analytical bindings survive preparation and refresh. The administrator page /county-operations.html shows organization-scoped refresh and source status. Thurston, Lewis and Pierce have live workspaces. Lewis and Pierce are Soldier Data-operated workspaces owned by James, not county-sponsored deployments. Their clinic listings remain source observations; no county participation or complete-inventory claim is implied. See scripts/counties/README.md for configuration, review and activation commands.

Facility verification

The facility verification page at /facility-review.html provides signed-in, project-scoped clinic review. It was activated with schema 60 on September 28, 2026 UTC. Select your organization, project, source, county and facility. View the source listing, then verify a source value, record a local correction, or withdraw a previous decision. Record the method, evidence, reason and verification date. Your signed-in identity and save time are recorded by the server.

Readers can inspect reviews; saving requires the existing review-comment permission in both the organization and project. Source permissions are checked for every read and save. The current clinic source policy admits owner, analyst and viewer; owner and analyst can save when both membership scopes permit it. A reviewer role alone does not add source access. If another reviewer saves first, or the source changes, reload before saving again. A changed source projection reopens prior reviews, including a subsequent reversion once the change has been observed. Changes in releases never read by this workflow cannot be detected by its journal.

Local decisions do not change source map records, approve annex exports, establish facility operating status, or automatically merge sites. The server workflow supports field verification, corrections and explicit physical-site assignments. A private operator command now transfers server reviews into county inventory snapshots with exact scope, revision and file-hash checks. A site-group directory, reminder delivery and operator-to-server history presentation remain follow-up work. The server journal and operator snapshots remain separate contracts; transfer is explicit.

For site grouping, choose Physical site assignment. Generate a new site ID for a new group, or enter an existing ID after confirming the records describe the same physical location. Use the same ID across clinic sources within the same organization, project and county; the same text elsewhere is a different group. Record evidence, reason, method and verification date for each assignment. Reassigning affects only the selected record. Remove site assignment to ungroup it without deleting history. Assignment values are visible in the history, and source changes or adopted review deadlines can reopen them. This page shows the selected record’s assignment; it does not list or certify all members of a group.

Verification age is calculated by the server when a review is loaded or saved. If the accepted county inventory defines reviewValidityDays, the page also shows the renewal deadline and marks overdue decisions. Source changes still require review independently of expiry. Counties without an adopted cadence show an explicit notice; no default schedule is assumed. Reload to update age. Pending county plans do not change the browser policy until their accepted bundle is deployed. This view covers server-journal decisions; operator-only review history is not mirrored into the browser.

Before activation, migrate a disposable database through schema 60, grant the runtime role SELECT and INSERT on lookout.facility_review_events, verify tenant and project isolation, and retain a tested pre-migration backup and a schema-60-compatible fallback application. After activation, application rollback keeps schema 60 and its journal; the original schema-59 application cannot pass readiness against schema 60. The journal has forced row security and rejects updates and deletes. Backup/restore checks must include facility_review_events with an explicit schema-60 pin. A source removal or revoked grant hides the record and review history from the UI while retaining the journal for authorized recovery.

For the one-way transfer, follow scripts/counties/TRUSTED-INVENTORY.md: extract the scoped journal using export-review-journal.mjs, import it with inventory.py import-server, and pin the new inventory in the county plan. Source-only changes preserve review holds through preparation and compilation. Conflicting local/server decisions and missing, rewritten or truncated history are rejected. File hashes prove integrity; accept transfer files only from the authorized operator extraction.

Automatic transfer is available in the operator tooling with an explicit serverReviewJournal.databaseUrlFile county-plan option. Every preparation imports a bounded, hash-verified journal snapshot before checking readiness. Once enabled, that inventory lineage requires synchronization; database failures or removal of the option fail preparation. Completed held candidates retain review history across scheduled refreshes, so source reversions cannot silently clear holds. Compiled releases retain private synchronization evidence without connection paths. Lewis and Pierce have enabled this option in their enrolled weekly plans, using a read-only database role restricted to their organization and projects. Enrollment and forced refresh reads passed with zero review events; no synthetic reviews were created. No review-expiry cadence has been adopted.

The RP-03 care-access extension is live in the authenticated facility review page. It adds labeled forms for hours, patient acceptance/referrals/telehealth, insurance/payment options, accessibility and service-specific reported appointment availability/wait days. Unknown is distinct from no or zero; unlisted days are not treated as closed, and insurance acceptance is not a plan-specific coverage guarantee. These are dated facility-level assertions with evidence, actor and history, not patient records or appointment forecasts.

The extension uses the same review permissions, source-change holds, expiry and withdrawals. It also updates private journal import and county refresh validation. Install the matching county operator runtime before the new API image; retain it on rollback once new-field decisions exist. Physical-site assignments do not automatically reconcile conflicting care assertions. The matching operator runtime is installed, and candidate/target/public checks passed for the September 29, 2026 UTC release. James retains review permission; the existing canary viewers remain read-only.

Private rural planning briefs

The initial rural planning workflow is an operator tool in scripts/rural. It creates a preliminary county-wide health/access brief, project-concept register and dated funding-criteria notes. It is not a shared browser editing page. The supplied funding catalog is Washington-specific; another state needs its own reviewed catalog.

Initialize a private workbook, retain every immutable revision, and build with a real export-capable account through the current analytical provider. The source permissions and project membership are rechecked before output. Keep the HTML, evidence JSON and file manifest together in private storage; print the HTML to PDF when needed. See scripts/rural/README.md for the CLI and protected host runner.

The September 28 Lewis brief contains five admitted county indicators, three unranked concepts and six program research entries. Rural-only estimates, actual facility capacity, eligibility determinations, drive times, site feasibility and county sponsorship are not established. Provider outreach was not performed. Closed rounds remain closed; open research becomes due after its catalog review date. Saved documents do not refresh themselves.

The reusable workflow has no database migration, new public route or source-rights change. Advanced service verification, eligibility mapping, routing, site feasibility, shared editing and the SDUS handoff follow the rural planning roadmap.

Shared rural planning workspace

The rural planning release provides the rural planning workspace and care service directory. Every signed-in page shares one header and task menu: Plan › Needs and site analysis, Explore › Care directory, Plan › Project register (rural planning), Review › Check clinic listings (facility verification), and Help for the planning guide. In the Project register, select an authorized county workspace, and create projects before adding tasks, funding criteria, sites, feasibility evidence, financial scenarios, travel scenarios and outcomes. Viewers cannot edit or export.

Every saved record retains its actual actor, revision and reason. Reload after a revision conflict. Withdraw dependent records before their parent project or site; history is retained. Blank amounts mean unknown, not zero. Evidence review dates and program-research dates are independent, and closed funding rounds remain closed.

Program screening keeps HRSA FORHP, USDA and Washington definitions separate. The retained official HRSA rural-tract list supports research lookup for 2020 census tracts; it does not replace the official analyzer or an exact solicitation. Other programs require their own official geographic and applicant screening.

Travel uses the pinned Washington OSM network and OSRM car profile, with network date, profile/image hashes, road time/distance, snap distance and route geometry. No road within 500 meters or no route yields no estimate. There is no live traffic, transit, patient-address processing or straight-line substitute. Extract boundaries and ferries can affect routes. Saving again creates a new calculation; earlier results remain in history.

Financial scenarios use supplied capital cost, annual operating cost/revenue, committed funding, years and discount rate. Missing amounts stop calculation. Compare saved scenarios in the same planning project; differences are suppressed when origins/network or financial horizons make them incompatible. These estimates exclude debt, tax, inflation and residual value and do not establish returns or demand.

The service directory shows source records with dated local assertions, expiry and source-change holds. Load remaining pages before treating a filter as county-wide. Site groups cover loaded filtered records; conflicts are shown, never automatically merged. The interactive street map shows loaded, filtered records over OpenStreetMap streets and place names. Drag to pan, use Zoom in/out or Fit locations, and select a marker for its name and review link. Street tiles need a network connection; the record list remains available when tiles fail. Follow a record link to review the exact authorized source.

Download the printable workbook and evidence/manifest under export permission. These outputs contain planning inputs and assumptions and any authorized saved site analyses, including their analytical maps and tract tables. Clinic records and the separate rural brief are not copied into this workbook. Open the HTML offline and print to PDF. Preserve the evidence and manifest for reproducibility. Soldier Data receiving integration has separate release acceptance; do not treat its older synthetic adapter as live.

Back up the journal and schema62 analytical snapshots with compatible operators and qualify a schema62-compatible API fallback before migration. Verify the road package hashes before starting the loopback-only routing engine; a failed/overdue network disables route calculation without fabricating results. See scripts/rural/PLANNING-WORKSPACE.md for preparation, bounds and recovery.

To hand off a project, download evidence and manifest, then open the Government CHIP reviewed-planning-input form in the existing local Soldier Data app at 127.0.0.1:14310. Import the JSON, choose a project and fill empty planning fields. Complete the actual reviewer, organization, ZIP, goal and scores before saving. The importer reports omitted tasks and shortened text; it does not supply eligibility or adoption decisions. A hosted Soldier Data receiving deployment is not established.

Evidence and site planning: from Explorer to a saved analysis

Open Explorer, select a county and tract indicator, then open Menu and choose Plan › Needs and site analysis. The link carries the authorized workspace, county, indicator and selected tract. Source values are read again from the server; compare the displayed source and period with your original Explorer layer. Unavailable indicators are explicitly identified rather than treated as equivalent to another measure.

On Evidence and site planning, select one to five admitted indicators and load evidence. Use the map layer selector and click a tract, or choose its GEOID, to inspect values, uncertainty, missingness, units and dates. The street map shows the candidate and loaded provider listings beside the analytical layer. Load additional provider pages before interpreting coverage, and follow a listing’s verification link to check services, patient access and capacity. Duplicate records, unverified availability and incomplete pages remain visible limitations.

Create or select a planning project. Create candidate sites with names and coordinates, using Pick location on map or manual coordinates. Select the candidate to analyze. Choose the whole county, a single selected tract, or a custom list built with Add selected tract to study area. Enter a driving threshold, analysis title and assumptions, then calculate and save. Saving requires edit and export permission because it retains authorized source evidence.

Access screening routes from one geometric interior reference point per tract to the saved candidate using the retained Washington car road network. It does not produce continuous drive-time isochrones or count residents actually within a drive-time area. Represented population is the population of tracts grouped by reference-point result. It is not a patient estimate. Missing routes remain unknown; published population margins of error and indicator confidence intervals remain visible. No prevalence averaging or age-adjusted prevalence multiplied by population is performed.

Select a saved analysis to view its access map and retained values. Compare two analyses only when county, planning project, tract cohort, source evidence, geometry, road network and threshold match. Choose explicit preferences for reference points within threshold and mean travel across jointly routed tracts. Unknown road results prevent a preference conclusion; no overall site recommendation is produced. Record costs, feasibility, capacity, criteria and unresolved questions in the planning register.

Download the private planning report or evidence JSON. The report includes schematic access and indicator maps, tract tables, sources, source identities, network assumptions and compatible pairwise comparisons. Reports present neutral comparisons; the interactive preference choices are not persisted. Clinic listings and verification assertions are contextual and are not included in these analytical exports. Current source and export permissions are checked again. If retained sources change or access is withdrawn, old values are hidden and the analytical report is blocked; load current evidence and save a replacement analysis.

A saved analysis is tied to the evidence it was calculated from, including whether the county's tract measures may be cited. If that changes for the county (for example when its citation rights are added, lapse or are withdrawn), the saved analysis is listed as “evidence unavailable” and opens with “Saved evidence is unavailable or changed. Reload source data and create a new analysis.” Nothing is deleted: load the evidence again and calculate a new analysis for the same site and indicators. Until every such saved analysis has been calculated again or withdrawn in the planning register, the county's planning report cannot be downloaded. Up to eight active saved analyses are supported per county workspace, with at most five indicators and 500 tracts per analysis. Use the planning register to withdraw superseded entries. Large evidence bundles may exceed downstream importer limits; the existing SDUS importer limit remains 8 MiB. Viewers can inspect authorized evidence but cannot create analyses or export. The map has a tract selector and table alternative if graphics or map tiles are unavailable.

Thurston Health Needs Assessment Pilot

Open /health-assessment.html. Use this private working assessment to connect geographic health evidence to community/provider findings and document why your team chose an action. A map identifies patterns; this workflow preserves the reasoning, source limitations, input, action owner and intended outcome. Both county/community and hospital-specific modes currently use whole Thurston County (53067); hospital mode does not calculate a facility service area.

What you get: a saved assessment, a printable HTML report (use browser Print to save as PDF), and a JSON evidence bundle containing source references and hashes. Lookout supplies selected admitted tract indicators; your team supplies the assessment question, period, reviewer, real engagement summaries, provider confirmations and decisions. This dashboard is not a public survey or an automatic report-writing service.

Choose the right tool. Use Explorer and evidence/site planning to investigate places, health patterns and provider locations. Use the Lookout assessment to connect that investigation to reviewed findings and actions. SDUS already provides CHNA/CHA and CHIP workflows with DOCX/PDF and provenance outputs, so start there when formal assessment or implementation deliverables are the primary job. You do not need to duplicate the assessment in both applications.

Handoff limit: this health assessment does not automatically transfer or synchronize with SDUS. The existing Lookout rural project/task importer is separate and does not accept this assessment bundle. If SDUS is your reporting workspace, bring reviewed Lookout findings across manually; do not assume shared records or review status.

Empty workspace: a blank assessment list means no assessment has been created. Choose Create your first assessment, complete setup and Save record. Evidence, input and report sections appear after saving. If the creation button is disabled, an editor with export permission must create it. Saved assessments remain available from the Assessment selector.

Illustrative example, not a Thurston finding: investigate barriers to diabetes care using an admitted diabetes measure and a transport indicator. Compare tract evidence and provider locations, then record a community transport concern and a dated provider confirmation. Link these inputs to a need, explain uncertainty and select an action with an owner and timeframe. A high tract rate alone does not establish clinic demand.

Roles and limits. Workspace viewers can read; editors can enter and review records. Creating or refreshing assessment evidence and downloading reports also requires export permission. Review identity and time are server-recorded. Internal review is not independent certification, hospital adoption, or public publication. Record those external actions and references in setup. Real community engagement, provider confirmation and institutional decisions must be completed by the participating team.

Up to six active assessments and 500 journal entities per county workspace; optimistic revision checks prevent overwriting concurrent changes. Reload after a conflict. Withdraw dependent needs before their inputs; existing history is retained. Custom or fractional service-area weighting, patient-level data and automated clinical recommendations are outside this pilot.

Hospital workflow reference: IRS CHNA guidance, checked September 29, 2026. The dashboard supports documentation and does not certify compliance.

1. Create an assessment. Select your organization and Thurston workspace, then Create your first assessment (or New assessment). Choose the assessment type, title, period, questions, reviewer and community definition. Hospital mode also requires a facility name and prior-assessment/comments context. Select one to five admitted indicators. Save with a reason.
2. Review evidence. Expand the tract maps and evidence table. Read native source periods, units, missingness, uncertainty and geography limitations. Use Open this evidence in site planning to investigate candidate locations and provider listings. Tract percentages are not averaged into a county estimate.
3. Add community input. Select Community input, then Add record. Record the represented group, collection method/date, findings, source reference, limitations, report permission and review status. Summarize surveys or meetings without participant names or individual health details. Hospital mode tracks public-health input, underserved/low-income/minority representation and prior-assessment comments or documented outreach.
4. Add provider input. Record a provider's services, confirmation method/date, accepting-patients status, capacity (unknown is acceptable), access barriers, evidence reference and review date. Registry presence alone does not establish operating capacity. Dashboard entries do not automatically overwrite the care directory.
5. Document needs and actions. Link community/provider inputs, cite indicators, and score burden, equity and community concern from 1 to 5. Equal-weight totals are transparent reviewer judgments, not modeled demand. Record the rationale, action or reason not addressed, responsible team and outcome/timeframe. Resolve investigate decisions before internal review.
6. Review and export. Resolve the progress checklist and record an internal review. Content edits, withdrawals and source changes invalidate the review. Download the selected assessment as a printable HTML report or JSON evidence bundle with hashes. Pending input permissions block export. Draft exports remain marked as drafts; permission and current-source checks still apply.

Healthcare inventory coverage and follow-up

Open Explore › Care directory from the task menu. Select the organization, workspace and county. Load whole county to traverse the authorized source pages. If loading fails, coverage remains partial; retry or reload before interpreting a county-wide search. Counts describe source records, not unique clinics or complete coverage of actual providers.

The coverage table separates current reviews, unreviewed fields, expired reviews and source changes. Select a field and enable Show records needing this field reviewed to focus the queue. Current means the existing review rules are satisfied; the page warns when a review-expiry policy has not been configured.

Create a planning project in Rural planning, then reload the directory. Expand Assign follow-up work, select the project and source record, specify a service focus, responsible team, due date, question and change reason. Saving creates an internal task in the shared journal; it sends no notification and does not contact the provider.

Follow the task link to Rural planning to update status and record outreach findings. Source references are retained when editing and cannot be removed or changed on a saved linked task. Open the source verification link separately to record dated assertions and evidence. Completing a task does not verify a facility or its services.

Open Care access planning for service-specific confirmations, structured outreach, provider submissions, reviewed alternatives and funding requirements. The default service recheck interval is 90 days with in-app reminders only. Read the healthcare service-planning guide below before using provider links.

Care access: verification, decisions and funding readiness

Open Care access planning from Explorer or the directory. Choose the authorized organization, workspace and county. Use the built-in guide, then add service confirmations or outreach attempts. Stable service categories include primary care, diabetes education, endocrinology, dialysis, urgent care, behavioral health and dental care. Preserve original wording; category suggestions do not establish service availability.

Confirm each service separately. Record source ID, acceptance, capacity, waits, hours, coverage and dated evidence. Blank numbers mean unknown. To mark a confirmation reviewed, name the individual fields checked in Fields reviewed (acceptance, capacity, waitDays, hours, coverage). A review of one service or field does not verify the rest of the facility. Source changes invalidate current service evidence.

Create a provider link for one source record and service, with 1–30 days until expiry. Copy the link when created; only its hash is retained. Share it through your approved channel. Anyone holding the link can submit once; it does not independently authenticate a provider. The form exposes no internal notes. Revocation, expiry, use, or loss of the issuer’s authoring membership prevents another submission. Staff must inspect the source, compare submitted fields and review supporting evidence; pending submissions do not alter the care directory.

The 90-day recheck default was approved for the operator-run pilot. A workspace may record a different cadence for new records; existing evidence dates remain explicit. Opening or reloading the workspace evaluates due dates and evidence changes, records in-app delivery attempts, and shows reminders. Acknowledgements suppress the same revision’s reminder; changed evidence creates a new reminder. Failed transactions retry on the next load. No emails, external notifications or provider messages are sent automatically.

County-wide directory search searches authorized source pages on the server. Results are paginated and bound to a content snapshot; changed data requires a fresh search. The map and other filters describe the shown page. Counts distinguish source records from unique facilities. Bounded source traversal is not proof that the underlying inventories include every provider.

For expansion planning, enter a baseline and alternatives under the same decision group and service. Record staffing, weekly capacity, capital and operating costs, revenue assumptions, commitments and feasibility. Use Evidence and site planning for actual route screens, then retain the analysis reference and exact population/network basis. Reference-point differences are suppressed when those bases differ. Sensitivity calculations are constant-cost/revenue scenarios, not forecasts or patient-demand estimates.

Record a decision with the selected alternative, evidence IDs, rationale, owner and target date. Add requirements for a specific funding opportunity with official sources, owners, due dates and linked evidence. Dependency revisions are retained; edits, withdrawals, overdue evidence and source changes flag affected requirements and decisions for re-review. Supported evidence is not an award or agency eligibility determination.

Export the decision/readiness report and evidence bundle under export permission. The packet includes service-planning assertions, source references and authorized inventory coverage counts; it excludes raw clinic listings. The receiving SDUS importer supports reviewed service decisions and reviewed health-assessment findings, checks scope/version/checksums, fills empty planning fields only and resets receiving acknowledgement. Import does not carry adoption, review authority or eligibility. The receiving SDUS deployment must be activated separately; file integrity is not publisher authentication.

Schema64 adds a scoped service journal, provider invitations/submissions and in-app notification audit. Deploy the matching API, frontend and backup/restore tooling. Keep a schema64-compatible fallback. Provider invitation tokens are secrets and must not be placed in logs or public documents. Exported packets and outdated downloaded files do not refresh automatically.