SAS Dashboard planning

SAS Dashboard: planning

Internal product planning for Sentinel Advisory Services (SAS). The SAS Dashboard is a resellable product for hospitals, with no to minimal per-hospital customization. Beachhead decisions (options and trade-offs in the 0-to-1 plan): first deployment is one Epic + Solventum/3M 360 Encompass facility; monthly Executive and Acute Care Coding views. The Product Owner owns the catalog and can ask a hospital for files; the Technical Owner is SAS privacy/security owner. SAS waits to build until a hospital pilot is selected.

These files are analysis and Working Backwards artifacts. They are not a launched product, not a signed-off architecture, not a metric formula catalog, and not customer or press collateral.

Start here

If you need… Read
The customer story for the first slice 0-to-1-pr-faq.md
What SAS is shipping first (in/out, done-when, open questions) 0-to-1-product-plan.md
The full vision, later increments, and deck inventory product-vision-and-roadmap.md
Stack and architecture options (no chosen stack) 0-to-1-tech-stack-architecture-evaluation.md
Open questions (roles, why each answer is needed) open-questions.md
Metric catalog workshop template metric-catalog/
The source vision deck SASDashboardVision.pptx

A new reader should take the 0-to-1 product plan and the PR/FAQ together, then the vision/roadmap only for what comes after the first hospital.

Documents

SASDashboardVision.pptx

Purpose: Source vision. SAS Dashboard Vision, Healthcare Revenue Cycle Leadership, Product Owner, 10 September 2026.

Leadership narrative with two illustrative dashboards. Not a data contract, metric spec, or implementation plan. Mock-up numbers are illustration.

0-to-1-product-plan.md

Purpose: First-slice product brief: the shipping definition of 0-to-1.

One-sentence product, beachhead (CFO + HIM at one Epic + 3M hospital), offer (configuration vs customization), in/out, done-when (hospital 1 trust + hospital 2 adapter), surfaces, catalog slots, delivery shape, 30/60/90, risks, and questions that still block the slice. Does not invent a named pilot, formulas, budget, or tech stack.

0-to-1-pr-faq.md

Purpose: Amazon-style Working Backwards press release and FAQ for that same first slice.

Customer-voice test of the brief: headline, what launched, persona quotes, customer FAQ, internal FAQ. Internal only. Not for distribution and not a claim that the product has launched. Must not outrun the 0-to-1 plan.

product-vision-and-roadmap.md

Purpose: Vision restatement and sequenced roadmap after the first hospital.

What the deck names (four focus areas, three view levels, source systems, mock-ups), gaps in the vision, increments 2–9 (encounter drill-through through multi-site packaging), production-ready destination, and slide map. The first slice is defined only in the 0-to-1 plan.

0-to-1-tech-stack-architecture-evaluation.md

Purpose: Technical options and tradeoffs for the first slice.

Presentation (client-tenant BI vs SAS-hosted BI vs custom app), ingestion (file/SFTP vs APIs/FHIR), tenancy, one-way vs incremental decisions, and questions that still steer the stack (hosting, data path, PHI grain, security bar). Does not lock a cloud, BI tool, or application framework.

open-questions.md

Purpose: Open questions grouped by CEO/Product Manager, CTO/Tech Lead, and hospital, with why each answer is needed. Source markdown; published HTML is generated. Copy tables from the generated page into email if needed.

metric-catalog/

Purpose: Example/template metric catalog for the Product Owner to use with a hospital. One-pagers for the 0-to-1 metrics, configuration sheet, denial-map stub, YAML slots. Template only: numerators stay TBD until the workshop.

Coverage checks

Scripts live in scripts/verify_docs/ (not in this folder). From the repository root:

python3 scripts/verify_docs/verify_0_to_1_plan.py
python3 scripts/verify_docs/verify_vision_roadmap.py
python3 scripts/verify_docs/verify_tech_stack_eval.py
python3 scripts/verify_docs/verify_docs_prose.py

They assert the briefs are substantial, grounded in the deck, that 0-to-1 stays a first slice, and that product markdown does not use em dashes.

Publish (Cloudflare Pages + Zero Trust)

Viewers do not need a Cloudflare account. They authenticate with a one-time PIN to an explicit allowlisted email. Do not use an email-domain rule.

Build the static site (rewrites markdown links to HTML, copies PPTX/YAML/email HTML):

python3 -m pip install markdown
python3 scripts/build_planning_site.py

Output is site/ at the repo root (not committed). Preview locally: python3 -m http.server --directory site.

Deploy (publisher must npx wrangler login once):

npx wrangler pages project create sas-planning --production-branch main
npx wrangler pages deploy site --project-name sas-planning

Production URL after the first deploy: https://sas-planning.pages.dev. Enable Access before sharing widely. Until Access is on, the URL is public.

Then in the Cloudflare dashboard:

  1. Enable Zero Trust on the account.
  2. Zero Trust → Identity providers → add One-time PIN.
  3. Pages project Settings → Enable access policy (previews).
  4. Zero Trust → Access → Applications: remove the * wildcard so production sas-planning.pages.dev is covered; enable the preview policy again so *.sas-planning.pages.dev is a second app (Pages known issues).
  5. On both apps, Access policy Allow only named emails (Product Owner, Technical Owner, each colleague). Default deny. Session e.g. 24 hours.

OTP mail comes from noreply@notify.cloudflare.com. Allowlist that sender if mail security consumes the PIN.

Each docs change: rebuild site/ and npx wrangler pages deploy site --project-name sas-planning. Do not put PHI, a named hospital, or BAAs on this site.

What this folder is not