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.
| 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 formatted for email | open-questions-email.html |
| 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.
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.
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.
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.
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.
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.
Purpose: The same open questions grouped by CEO/Product Manager, CTO/Tech Lead, and hospital, with why each answer is needed. HTML for paste into email. Open in a browser, select the tables, and copy into the compose window.
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.
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.
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:
* 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).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.