SAS Dashboard: 0-to-1 Product Plan

Organization: Sentinel Advisory Services (SAS)
Vision source: docs/planning/SASDashboardVision.pptx: SAS Dashboard Vision, Healthcare Revenue Cycle Leadership, Product Owner, 10 September 2026
Related: Working Backwards PR/FAQ: docs/planning/0-to-1-pr-faq.md; metric catalog template: docs/planning/metric-catalog/; full vision and later increments: docs/planning/product-vision-and-roadmap.md; architecture options: docs/planning/0-to-1-tech-stack-architecture-evaluation.md
Document type: First-slice product brief. Not a technical spec, not a metric formula catalog, not a signed-off architecture, not the full product vision.

The SAS Dashboard is a resellable product for hospitals, with no to minimal per-hospital customization. This brief defines the first deployment of that product.

Staffing (SAS): The Product Owner can ask a hospital for files and owns catalog delivery. The Technical Owner is the SAS privacy/security owner. There is budget for this work. SAS waits to build until a hospital pilot is selected. The vision deck remains sales collateral, not a substitute product.

Open items stay questions. This document does not invent a named pilot, metric formulas, a price, or a tech stack.

1. The product (one sentence)

One Epic + Solventum/3M 360 Encompass hospital (or single facility inside a system): a monthly Executive mid-cycle view plus an Acute Care Coding manager view, fed by agreed extracts, covering DNFB, DNFC, CMI, CC/MCC capture, min/chart productivity, coding quality/audit accuracy, and coding vs clinical-validation denials.

That sentence is the current beachhead, not the only conceivable first product. §3 records the options, trade-offs, and why this pair (surfaces + Epic/3M) is the decision remaining documentation assumes. A second Epic + 3M hospital gets the same two views and the same catalog through configuration and an extract adapter, not a rebuilt dashboard.

2. Problem

Mid-cycle revenue cycle is where documentation, coding, DRG/severity capture, and cash consequences meet. Today, at the hospitals this product is for:

• Data sits in silos. Coding, CDI, quality, and billing metrics each live in a different vendor tool with a different definition.
• Reporting is manual. Leaders wait on spreadsheets assembled by hand, so the numbers arrive late and rarely agree.
• No line of sight. A CFO can see the dollars but not what in coding or documentation is driving them.

Pre-service and point-of-service are context. The first product is mid-cycle acute-care coding connected to executive cash metrics (DNFB, CMI, denials).

Hospitals already have pieces of this picture: Epic Cogito/Caboodle reports, 3M 360 Encompass operational reports, and the HIM/CFO spreadsheet. None of those is a single, SAS-owned, copyable catalog that a second hospital can run without a consulting rebuild. That is the gap this slice fills.

3. Beachhead decisions

The vision names four focus areas, three view levels, and many source systems. MLP (1st product slice) cannot be all of them. Two decisions need alignment below. Remaining sections of this brief, the PR/FAQ, the vision/roadmap sequence, and the tech eval assume the recommendation unless they are reopened.

3.1 Decision A: first product surfaces

What hospital 1 logs into.

Recommended: Monthly Executive mid-cycle view plus Acute Care Coding manager view. Why: only pair the deck draws; one HIM director and one CFO can sit down on the same extracts; CDI operations, encounter, Profee, and Quality stay later.

3.2 Decision B: first source path

Which hospital can be hospital 1.

Recommended: Hospital 1 must run Epic for acute care and 3M 360 Encompass for coding/CDI (one facility). Why: illustrated path, extract inventory, copyable catalog. Other EMRs and CAC tools wait.

3.3 Who this slice serves (given A and B)

Customer: One hospital (or one facility inside a system) that runs Epic for acute care and Solventum 3M 360 Encompass for coding/CDI.

Buyers and users this slice serves

CDI Directors see CMI and CC/MCC on the executive view. Their own query/agreement dashboard is not in this slice. Coders and auditors do not get an encounter worklist in this slice. Quality / Compliance is not a first-slice surface.

The economic buyer (CFO vs HIM vs SAS’s own delivery team) is still an open question. The views assume a CFO and an HIM director will sit down together.

4. Offer

The dashboard is sold across hospitals with no to minimal customization. The first site is a deployment of the product, not a unique analytics workspace.

SAS owns the metric catalog (versioned change control). The hospital owns configuration: targets, facility names, calendar/fiscal period, extract column maps, denial-code rows in the product mapping table, and named users.

Allowed configuration

• Facility identifiers and display names.
• Client-provided targets.
• Calendar / fiscal period used to bucket the trailing six months.
• Column and file mapping from the hospital’s Epic / 3M / remit extracts into the canonical extract contract.
• Denial-code rows (their CARC/RARC or equivalent → product “coding” vs “clinical validation” buckets).
• Named users for the two views.

Not allowed (customization)

• A forked DNFB, DNFC, CMI, CC/MCC, min/chart, quality, or denial formula.
• Extra tiles, filters, or a unique layout for one HIM director.
• One-off SQL or BI measures that do not live in the versioned catalog.
• A different grain, a third dashboard, or Quality / Profee / encounter worklist “just for this site.”
• Rebuilding the semantic model because the first hospital’s spreadsheet used a different clock.

If a hospital’s operational definition cannot be expressed as catalog version + parameters, either the catalog gains a documented product parameter (a product change, sold to every hospital) or that hospital is a no-fit (not a custom build).

Hosting (SAS-hosted vs the same product deployed into the hospital tenant) is open. Forking the first hospital’s workspace is not.

5. In scope

• One focus area: Acute Care Coding. Inpatient first; outpatient on the same dashboard only if the same extract already has it (the mock-up shows both).
• Two of three view levels: Executive + Manager (acute care coding). Same underlying extracts so the CFO’s DNFB/CMI/denials and the HIM director’s DNFC/productivity/quality are one story.
• One source path: Epic (ADT / hospital billing / A/R unbilled) + Solventum 3M 360 Encompass (coding, CDI-derived severity, CMI, CC/MCC). Denials from the hospital’s claim/remittance extract mapped into the product coding vs clinical-validation taxonomy. Mapping table is configuration; buckets and formula are not.
• One grain: monthly, trailing six months, matching the mock-ups.
• One facility as the first deployment. Not multi-EMR, not self-serve multi-tenant. Artifacts must be reusable by the next Epic + 3M hospital.
• SAS-owned metric catalog, proven on the first hospital. The workshop validates the catalog against their reports. It does not mint a private formula set. Until that first version exists, do not code formulas as if they were known.
• Targets are configuration: hospital-provided (the mock-up’s ≤5.0 DNFB, ≤3.0 DNFC, ≥95% quality, ≤4.0% denials are illustration). Do not ship a peer-benchmark network unless the hospital supplies the file.

6. Out of scope

The full vision inventory and the increment sequence after this slice are in docs/planning/product-vision-and-roadmap.md.

7. Done when

Hospital 1. A HIM director and a CFO (or VP Revenue Cycle) at one Epic + 3M site can sit down, look at the two views, and make at least one of the decisions in §3 (where cash is delayed / which denial category to fix, or staffing, overtime, vendor volume, who needs coaching) from the same underlying extracts, without waiting on a hand-built spreadsheet.

Hospital 2 (resale bar). A second Epic + 3M hospital can be onboarded onto those same two views and the same catalog with configuration plus an extract adapter. If hospital 2 requires core formula or layout changes, this slice failed even if hospital 1 is happy.

This is not every focus area, every EMR, every role, or a production-grade HIPAA platform. It is also not a unique workspace per hospital.

The repository is greenfield: no application, ETL, auth, hosting, or customer data. This slice is a product and delivery problem, not “finish the remaining screens.”

8. Surfaces and grain

The vision deck mocks up exactly two screens. Those are the 0-to-1 surfaces. Mock-up numbers are illustrative (labeled MOCK-UP FOR ILLUSTRATION): not a client’s data, not a pixel spec, and not a formula spec.

Executive: “Mid-Cycle Performance · Trailing 6 Months”

• KPI tiles: DNFB, CMI, CC/MCC capture, coding + clinical denials.
• Monthly DNFB trend vs a hospital-provided target.
• Monthly denial-rate split: coding vs clinical validation.

Acute care coding manager: “Inpatient & Outpatient Coding Operations · Trailing 6 Months”

• KPI tiles: DNFC, IP min/chart, OP min/chart, coding quality (all).
• Monthly DNFC trend vs target.
• Productivity vs a hospital-provided benchmark line if they supply one; otherwise omit the peer/benchmark decoration.
• Quality breakdown: IP DRG, POA/HAC, OP APC & CPT, ED E/M vs target.

Grain: monthly, trailing six months, not a real-time coder worklist.

9. Metric catalog slots

Named metrics for this slice (definitions are a starting point, not a final spec; the workshop fills numerators):

• DNFB: Discharged Not Final Billed (gross A/R days unbilled). Executive.
• DNFC: Discharged Not Final Coded. Manager.
• CMI: Case Mix Index. Executive.
• CC/MCC capture. Executive.
• Min/chart productivity: IP and OP separately if the extract has both.
• Coding quality / audit accuracy: overall plus IP DRG, POA/HAC, OP APC & CPT, ED E/M.
• Coding vs clinical-validation denials: % of billed charges denied, split coding vs clinical validation, plus combined.

SAS owns each metric’s id, version, effective dating, and source fields. A formula change is a catalog version, not an in-place edit that silently rewrites history. Do not code numerators until the workshop writes them against real fields.

Workshop template (one page per metric, configuration sheet, YAML example): docs/planning/metric-catalog/. Copy it for the named facility; do not treat 0.1-template as signed v1.

10. Data and delivery shape

Not a stack pick. Option families (client-tenant BI vs SAS-hosted BI vs custom app; file drop vs APIs) are in docs/planning/0-to-1-tech-stack-architecture-evaluation.md.

This is shape, not a stack pick. Who hosts the boxes is open.

Shape this slice requires

1. Product catalog first: one page per named metric: numerator, denominator, exclusions, grain, source field, owner (SAS), version, which knobs are configuration. The first HIM/CFO sign that they can run the hospital on that catalog.
2. Canonical extract contract: the smallest set of fields the product needs. The hospital may drop files they already produce (Epic Clarity/Caboodle or standard financial reports; 3M 360 Encompass productivity/quality/CMI reports; denial/remit file) via SFTP or secure share. SAS maps those files into the canonical model (an adapter). The warehouse schema is not “whatever hospital 1 sent.” No new vendor API if an existing report fills the contract.
3. Shared semantic layer + the two views: a deployable dataset/report SAS owns. A BI tool in a hospital tenant is acceptable only if the model is a product artifact SAS can copy to hospital 2. SAS-hosted BI is the alternative if the hospital will not take that model, or if SAS hosts. Recreate the two mocked views with this hospital’s numbers on the product catalog.
4. Weekly or monthly refresh. Manual is acceptable for the first two cycles; then a parameterized load script (product, not a one-off notebook).
5. Review against both done-when tests in §7. If the spreadsheet wins by forking the formula, that is a catalog decision or a no-fit, not a silent customize. Do not add a third dashboard.

A custom web application, FHIR integrations, and a SAS-branded login are not required to prove the first hospital’s numbers. They are packaging. Do not rebuild the deck mock-ups in a custom UI with fake data.

If no pilot is selected: wait. Do not staff a UI. Filling DNFB from mock-up tiles is not product work. The existing deck is the sales artifact.

11. Plan to first value

A calendar needs a named Epic + 3M hospital and a data-sharing path. Until a hospital pilot is selected, SAS waits: no UI, no fake-data product. Product Owner may draft catalog slots and the configuration boundary; formulas and extracts wait on the named site. The vision deck remains sales collateral.

If a pilot with Epic + 3M can be named:

• Days 1–30: Catalog one-pagers (formulas filled only from workshop + real fields). Configuration-vs-customization page. Canonical extract contract. Inventory of the hospital’s existing files mapped to that contract. BAA / security questionnaire started. No UI beyond sketching the two mock-up views onto the catalog. Quality, Profee, and encounter parked.
• Days 31–60: First load of historical six months into the canonical model. Two product views populated. Reconciliation against the hospital’s spreadsheets. Catalog version corrections (product changes), not a fork. First live review with CFO / HIM Director.
• Days 61–90: Parameterized refresh. Written “what this is / is not,” including “not a custom dashboard.” Decide: extend the pilot, add encounter drill-through (next increment), or stop. Capture catalog v1. Ask explicitly: could a second Epic + 3M hospital go live on this with adapter + config only?

If no pilot is selected: wait. Do not staff a UI or a fake-data app. The deck is the leave-behind. Catalog slots and the configuration page may be drafted; numerators and extracts wait.

Price the first site as a paid pilot of the product (or a subscription that starts at the pilot), not unpaid R&D and not an unscoped engagement add-on that implies customization.

12. Risks that can kill this slice

• No data, no product. Without a named hospital and a legal path to extracts, the only build is another mock-up.
• Definition wars. DNFB and DNFC clocks are site-specific. The catalog is product-standard. A mismatch is a documented configuration parameter, a catalog version, or a no-fit (not a quiet fork for that CFO).
• Denial split is a mapping project. Coding vs clinical-validation is not a standard field. Wrong mapping produces a confident, wrong executive chart.
• Customization pressure. The paying hospital will ask for “just this one extra tile” and “our DNFB.” The configuration boundary has to be in the room.
• A one-off workspace. A Power BI file (or equivalent) whose measures exist only in that tenant can be live in weeks and cannot be sold to the next hospital. The model must be a SAS-owned, copyable artifact. Hosting remains open; unique measures do not.
• IT security review as the silent critical path. A file drop into a SAS cloud still hits the hospital’s vendor-risk questionnaire. Start that paperwork the week the hospital is named.
• PHI and HIPAA. Even facility-level extracts with dates of service can be PHI or a limited data set. Hosting without a BAA, minimum necessary, and access logging is legal risk from the first real file. Monthly KPIs might be de-identified aggregates. That is a question for counsel, not an assumption.
• Epic access is political. Clarity/Caboodle sits with hospital IT and a ticket queue. Prefer files they already produce.
• mmmDB permission. Do not block this slice on it.
• Scope from consulting SMEs. Local quality scorecards stay out unless they become a product surface sold to every hospital.

Production-ready and fastest-to-market pull opposite directions. Sequence: decision-useful connected view first, production controls as soon as real data exists, full vision last. Claiming both on day one is how this does not ship.

13. Open questions that block this slice

Staffing facts (not questions): The Product Owner can ask a hospital for files and owns catalog delivery. The Technical Owner is SAS privacy/security owner. SAS waits until a hospital pilot is selected. SAS owns catalog definitions; the hospital owns configuration. Metric numerators are a workshop, not architecture.

SAS: company and offer

1. Who is the economic buyer: CFO, VP Revenue Cycle, HIM, or SAS’s own consulting delivery team?
2. What should be true in 6 months once a pilot is named: a live product with a first hospital’s numbers and a credible hospital-2 onboarding path? (A branded-demo build is out: SAS waits for a pilot. A one-off internal engagement tool contradicts the offer.)
3. How is the first site priced: pilot fee or software subscription? An unscoped engagement add-on that implies per-hospital build conflicts with the offer.
4. What does SAS count as this worked (paid pilot signed, spreadsheet retired, hospital-2 path proven, other)? The vision deck does not say.

Hospital: site, data, hosting, and security

The hospital must answer these. SAS engineering cannot decide them alone.

1. Who is the first hospital, and do they run Epic + 3M 360 Encompass today?
2. Will the hospital allow SAS to host, or must the same product stay in the hospital tenant?
3. If hospital tenant: does SAS receive files (SAS sees PHI/LDS) or only send a deployable artifact?
4. If SAS hosts: which cloud account and region will that hospital accept?
5. Is a BAA in place or startable now? What is the vendor-security questionnaire timeline?
6. What data-sharing path is available (SFTP of existing reports, Clarity/Caboodle, 3M subscription, mmmDB)?
7. What files do they already produce weekly/monthly for DNFB, coding productivity, 3M CMI/CC/MCC, audit, and denials?
8. What join keys do they already use across Epic unbilled, 3M, and remit?
9. Who operates SFTP/the share, and what refresh SLA will they commit to?
10. Will mmmDB be allowed for this hospital, or is that off the table?
11. What security bar will the first hospital require (MFA, SSO, SOC 2, HITRUST, region)?
12. Aggregate-only KPIs vs row-level encounter data: which will the hospital actually send?
13. What is the actual file grain (facility-month, encounter limited data set, mixed)?
14. What is the exit if the numbers cannot be reconciled to the hospital’s existing reports within two cycles?

Metric workshop (HIM + CFO with SAS catalog owner; do not invent here)

1. DNFB: clock start/stop, included patient types, whether authorization/medical-necessity holds count, gross vs net, dollars vs days?
2. DNFC: same, plus whether CDI query pending pauses the clock, and vendor vs in-house coding?
3. CMI: MS-DRG vs APR-DRG vs both, final-billed vs working DRG, which 3M grouper version?
4. CC/MCC capture: which methodology (CMS, 3M, hospital-specific), population (all IP vs ranked services)?
5. Min/chart: which statuses count, how a “chart” is defined for OP/ancillary vs IP, re-codes, productive hours source?
6. Coding quality / audit accuracy: whose audit, sample design, scoring, how ED E/M is scored?
7. Coding vs clinical-validation denials: % of billed charges vs claims vs dollars; which CARC/RARC map to which bucket; are appeals outcomes in the rate?

Scope still open inside this slice (SAS with hospital input)

1. Inpatient-only vs IP+OP on the first acute dashboard?
2. Single facility vs system roll-up for the first hospital?
3. Is anyone blocked if the first ship is monthly rather than daily?

14. Non-goals of this increment

• No application, ETL, auth, or hosting implementation in this repository yet.
• No chosen tech stack presented as settled fact.
• No production SQL or 3M/Epic interface spec written as if access exists.
• Mock-ups are not pixel-perfect UI and not real hospital data.
• No four-focus-area, all-EMR, all-three-levels product.
• No competitive teardown, pricing model, or HIPAA policy beyond naming them as risks and questions.

Architecture options: docs/planning/0-to-1-tech-stack-architecture-evaluation.md. Vision and later increments: docs/planning/product-vision-and-roadmap.md.