SAS Dashboard: 0-to-1 Technical Stack and Architecture Evaluation

Organization: Sentinel Advisory Services (SAS)
Grounding sources: docs/planning/0-to-1-product-plan.md (first slice); docs/planning/0-to-1-pr-faq.md (Working Backwards customer narrative); docs/planning/product-vision-and-roadmap.md (later increments); docs/planning/SASDashboardVision.pptx
Document type: Technical options analysis. Not a signed-off architecture, not a stack decision, not a metric formula catalog, not a HIPAA policy.
Offer (from the 0-to-1 plan): resell across hospitals with no to minimal per-hospital customization. The first ship is a repeatable product deployment. Beachhead decisions (0-to-1 plan §3): Executive + Acute Care Coding manager; Epic + 3M 360 Encompass. Hosting, data path, PHI grain, and the first hospital’s security bar are hospital questions. The Product Owner owns the catalog; the Technical Owner is SAS privacy/security owner. SAS waits to build until a hospital pilot is selected.
Stance: Compare option families with explicit tradeoffs. Recommendations are labeled suggestions. Open items stay questions. This document does not invent a named pilot, does not invent metric formulas, does not lock a tech stack, and does not treat later increments as 0-to-1 must-haves.

1. Why this document exists

The 0-to-1 product plan defines the first slice and forbids locking a tech stack. The dashboard is a resellable product: no to minimal per-hospital customization. Surfaces (Executive + Acute Care Coding) and source path (Epic + 3M 360 Encompass) are beachhead decisions in that plan, not unexplained defaults. Hosting, data-sharing path, PHI grain, and the first hospital’s security bar are hospital questions. Engineering needs a map of what is choosable, what each choice costs later, and which questions close the map.

That offer does not turn 0-to-1 into a four-focus-area multi-EMR SaaS platform. It does rule out a one-off advisory workspace whose measures, layouts, or extract schema cannot be reused by the next Epic + 3M hospital.

This evaluation:

1. Restates the known constraints any stack must respect.
2. Compares multiple stack and architecture option families, with tradeoffs, for presentation, ingestion, and tenancy.
3. Classifies decisions as one-way door vs incremental / reversible.
4. Lists questions that still need answers before technical direction can be fine-tuned, distinct from facts the product plan already settled for the 0-to-1 slice.
5. Records other technical information the stack choice depends on (PHI grain, increment sequencing, metric versioning, freshness, authz, production destination).

It does not pick a cloud vendor, BI tool, warehouse, or application framework as settled fact. A sentence of the form “the architecture is X” would contradict the product plan.

2. Known constraints any stack must respect

These are the assumed beachhead from 0-to-1 plan decisions A (surfaces) and B (Epic + 3M). Options and trade-offs for those decisions live in the 0-to-1 plan §3. They are not reopened here as a stack pick. A stack option that violates them is not a 0-to-1 option; it is a later-increment option wearing a 0-to-1 label.

2.1 Slice (assumed beachhead)

Assumed 0-to-1 slice: 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.

Also assumed (given those decisions):

• One focus area: Acute Care Coding. Inpatient first; outpatient on the same dashboard only if the same extract already has it.
• Two of three view levels: Executive + Manager (acute care coding). Encounter detail is increment 2, not a v1 tab.
• One illustrated source path: Epic (ADT / hospital billing / A/R unbilled) + Solventum 3M 360 Encompass (coding, CDI-derived severity, CMI, CC/MCC). Denials from the client’s claim/remittance extract mapped into a product “coding” vs “clinical validation” taxonomy; the hospital’s codes go in a mapping table (configuration), not a forked metric.
• One grain: monthly, trailing six months, matching the mock-ups. Daily-while-inpatient refresh is increment 4, not the first ship.
• First deployment is one facility: a single pilot facility (or SAS-operated instance for that pilot). Not multi-EMR, not self-serve multi-tenant on day one. Artifacts must be reusable by the next Epic + 3M hospital with configuration and an adapter.
• SAS-owned metric catalog, proven on the first hospital: show named metrics from a product catalog the first HIM/CFO reconcile in writing. The workshop validates; 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: client-provided only. Do not ship a peer-benchmark network in 0-to-1 unless the client supplies the file. Changing a target is not customization; changing a numerator is.

What “done” means (known): a HIM director and a CFO (or VP Revenue Cycle) at one Epic + 3M site can make at least one slide-9 decision from the same underlying extracts, without waiting on a hand-built spreadsheet. Resale bar: a second Epic + 3M hospital can be onboarded onto those same views and catalog with configuration plus an extract adapter. It is not “every focus area, every EMR, every role, production-grade HIPAA platform,” and it is not a unique workspace per hospital.

2.2 Explicitly deferred (not v1 must-ship)

The 0-to-1 plan parks these. This evaluation does not pull them into 0-to-1 stack requirements:

2.3 Delivery shape (0-to-1 plan: shape set, stack not)

The 0-to-1 plan sets a shape, not a stack: the first ship is a deployment of a repeatable product. Hospital 2 must get the same two views via configuration and an extract adapter. Self-serve multi-tenant hardening is increment 9 in the vision and roadmap.

Practical pattern (tooling still optional):

1. SAS-owned product catalog first (one page per metric, versioned; workshop validates, does not fork).
2. Canonical extract contract: the hospital may still drop files they already produce; SAS maps them into the canonical model (adapter). SFTP or secure share; no new vendor API if an existing report will fill the contract.
3. Shared semantic layer + the two views that SAS can copy to hospital 2. Power BI (or equivalent) in a client tenant is acceptable only if the model is a SAS-owned product artifact, not undocumented measures. SAS-hosted BI is the alternative if the client will not take that model, or if Q9 says SAS hosts.
4. Weekly or monthly refresh; manual acceptable for the first two cycles; the load script is parameterized product, not a one-off notebook.
5. Pilot review against two tests: CFO/HIM trust vs spreadsheet without forking the formula, and “could hospital 2 go live on this with adapter + config?”

A custom web application, FHIR integrations, and a SAS-branded login are still not required to prove the first hospital’s numbers. They are packaging options for resale. They are not an excuse to skip the catalog or to rebuild slides 10–11 with fake data.

Configuration vs customization is a technical constraint: targets, facility names, column maps, and denial-code rows are configuration. Forked formulas, extra tiles, unique layouts, and one-off SQL are not.

2.4 Advisory vs software tension (known risk)

The offer is a resellable product. A custom Power BI in the client tenant, with measures that only exist in that file, can still be live in weeks and cannot be sold to the next hospital. A SAS-owned model (hosted by SAS or deployed as the same artifact into a client tenant) is slower to first value and is what resale requires. Hosting is an open question. Forking the first hospital’s workspace is not an option.

2.5 Workspace state (known)

The repository is greenfield: no application, no ETL, no auth, no hosting, no customer data. 0-to-1 is a product and delivery problem, not “finish the remaining screens.” There is no incumbent stack to extend.

2.6 Production destination vs day one (known)

The vision and roadmap lists what production-ready will require. That list is a destination, not day-one scope. Several controls (BAA, encryption, named-user access, extract freshness) must start in increment 1 as soon as real data is used; hardening and evidence (policies, pen-test, SSO, uptime target) wait. See §10.6 of this evaluation.

3. What this evaluation is not deciding

Left open on purpose (the product offer is not in this list; it is a resellable product):

• Cloud vendor (Azure / AWS / GCP / client Microsoft 365).
• Specific BI product as the product (Power BI is an example of a presentation skin, not a signed decision).
• Warehouse product (Fabric, Snowflake, Databricks, DuckDB, none).
• Custom application framework.
• Who hosts PHI (Q9): SAS-hosted vs the same product deployed into the hospital tenant.
• Whether 0-to-1 data is aggregate-only, a limited data set, or row-level encounter PHI.
• Metric numerators, denominators, and denial CARC/RARC maps (catalog v1 is filled in the workshop; ownership is SAS).

The dashboard is not a per-hospital consulting workspace. A stack option that only works as a one-off is not a 0-to-1 option.

If a later reader treats any option below as “the architecture,” they are misreading this document.

4. Option family A: Presentation and delivery surface

Question this family answers: what does the CFO and HIM director actually log into for the two mocked views?

Three honest options exist. They are not three skins of the same system. They imply different identity, PHI, packaging, and later-increment paths.

4.1 Option A1: Client-tenant BI workspace

What it is: the two views live in a BI workspace the client already trusts and already has accounts for. The product plan names Power BI in the client tenant as a common pattern; Tableau, Looker, Qlik, or the client’s existing Epic Cogito/Caboodle reporting portal are the same family if that is where the buyer already logs in.

How 0-to-1 would look: SAS (or the client analytics team) publishes an Executive report and an Acute Care Coding manager report against a dataset loaded from agreed extracts. Access is the client’s Entra ID / Okta group. SAS may be a guest user, or may never log in and instead ship a .pbix / workbook and a load script.

Tradeoffs: what this makes easy:

• Fastest calendar time to a live number the buyer already knows how to open. Matches “weeks, not a product platform.”
• Identity, MFA, and often SSO are already the client’s problem. Vendor-risk review is smaller if no new SAS-hosted system stores PHI.
• File import / scheduled refresh is a solved motion in these tools. Manual first two cycles fit naturally.
• Reconciliation with the client’s old spreadsheet is social, not technical: the same people already live in this workspace.

Tradeoffs: what this makes hard:

• Productization is the tax, and under the resale offer it is a 0-to-1 failure mode, not a later problem. A client-tenant Power BI (or equivalent) whose measures, RLS, and gateway config exist only in that tenant cannot be resold. This option is viable only if the semantic model and catalog live outside the hospital’s file and can be deployed to hospital 2 unchanged (see §7.1). Otherwise A1 is a consulting workspace and contradicts the offer.
• SAS does not control release, theming, or who sees which page, except by convention.
• Encounter drill-through (increment 2) is possible with row-level security, but coder-grain authz and “why was this flagged?” UX are a poor fit for a monthly executive dataset.
• Daily mid-stay refresh (increment 4) depends on the client’s gateway and extract, not on SAS ops.
• Second EMR adapter (increment 7) is a second dataset in a second tenant, not a connector library.
• If the model is not SAS-owned and deployable, this option fights the resale goal even when Q9 says “must stay in the client tenant.” Q9 then means “deploy the same product artifact into their tenant,” not “build them a unique workspace.”

Later-increment fit: acceptable for increment 1 only with an external catalog and a copyable dataset. Poor as the long-term product surface if SAS later wants a branded login and self-serve onboarding (increment 9). A unique A1 workspace with no catalog is not increment 1 under the current offer.

4.2 Option A2: SAS-hosted BI

What it is: SAS operates a BI tool (Power BI Embedded, Tableau Cloud, Looker, Metabase, Superset, or similar) in a SAS cloud account. The pilot logs into a SAS-controlled workspace. Same two views, same monthly grain.

How 0-to-1 would look: extracts land in a SAS-operated store; SAS publishes the two reports; named pilot users get accounts. This is still a single-pilot analytics workspace, not multi-tenant SaaS. The product plan names this as the alternative “if the client will not share a workspace.”

Tradeoffs: what this makes easy:

• SAS controls the semantic model, refresh, and visual version. Easier to copy the workspace for a second pilot than to harvest a client-tenant file.
• A path toward productization that does not require writing a custom app on day one.
• Demo and internal engagement use (Q3) can share the same tool, with synthetic data, without waiting on a client tenant.

Tradeoffs: what this makes hard:

• PHI hosting and BAA become the critical path the moment real files arrive (0-to-1 plan risks, Q9, Q10). IT security review is “the silent critical path” (§8.3). This option cannot skip that paperwork.
• SAS must now run identity (or broker SSO), encryption, backup, access logging, and extract monitoring (increment 5 concerns that start as soon as real data exists).
• Slower to first trusted number than A1, for no additional decision-usefulness on monthly tiles.
• A hosted BI tenant with two reports is still not increment 9 (self-onboarding, entity model, connector library). The logo on the login page does not create a connector library. It does make hospital 2 a copy of a SAS-owned workspace rather than a harvest of a client file, which is what resale needs.
• If the first client’s security bar is “nothing leaves our tenant” (one possible answer to Q9), this option is closed for that pilot regardless of SAS preference.

Later-increment fit: better than A1 for a second site and for a versioned metric catalog SAS owns. Encounter drill-through still pushes the BI tool toward an operational app it is not. Custom UI can replace the BI skin later if the catalog and warehouse are separate.

4.3 Option A3: Custom web application

What it is: a SAS-branded application (typical shape: a web front end, an API, an identity provider, a warehouse or OLAP store) that renders Executive and Acute Care Coding views, with SAS-controlled auth.

How 0-to-1 would look: engineering stands up hosting, auth, CI, and two dashboards, then waits on the same extracts and the same SAS catalog as A1/A2. The product plan is still explicit: a custom web application, FHIR integrations, and a SAS-branded login are not required to prove the first hospital. They are packaging for resale. Building A3 with formulas in route handlers and no catalog is still a trap.

Tradeoffs: what this makes easy:

• Role-based screens that match slide 9 (CFO vs HIM vs later CDI vs later coder) without fighting BI RLS.
• Encounter worklist, drill-through that reconciles to the tile, and “why was this flagged?” are natural increment 2/3 work in an app, awkward in a monthly BI report.
• Multi-tenant product packaging (increment 9) has a place to land: orgs, roles, connectors, audit.
• Visual fidelity to the deck mock-ups is controllable, but the product plan warns not to spend 0-to-1 engineering time rebuilding illustrative tiles with fake data and calling it a product.

Tradeoffs: what this makes hard:

• Slowest path to a CFO/HIM decision from real numbers. Auth, hosting, and vendor-risk land before the first trusted DNFB tile.
• Greenfield repo has no application; this option creates the entire production surface as the first slice. That can still waste the 0-to-1 window if it delays the first trusted numbers. Catalog + canonical extract are the product; the custom UI is packaging.
• PHI, BAA, MFA/SSO, audit logs, encryption, backup are all on the critical path, same as A2, plus application security (session, IDOR on later encounter routes).
• Metric formulas hidden in application code are as trapped as formulas hidden in a Power BI measure. A custom app without a versioned catalog is not more “product-like”; it is a different trap.
• If no pilot is named (Q6/Q7), a custom app with synthetic data recreates slides 10–11 in another tool (the product plan’s explicit anti-pattern).

Later-increment fit: best destination packaging for resale and for increment 2+ (encounter, roles). Still a poor first move if it delays catalog + first trusted numbers. Compatible with the resale goal if the catalog/model are built first and the app wraps them.

4.4 Presentation family: comparison

Suggestion (not a stack decision): the live 0-to-1 fork is A1-as-deployable-product-artifact vs A2, gated on Q9 (will the client allow SAS to host, or must the same product stay in the client tenant). Treat A3 as packaging for resale and increment 2+, not as a fake-data UI, and not as a substitute for the catalog. A1-as-unique-consulting-file is out. Do not rebuild the mock-up with fake data.

5. Option family B: Ingestion and data path

Question this family answers: how do Epic, 3M 360 Encompass, and denial/remit facts arrive for a monthly, trailing-six-month load?

The product plan’s illustrated path is Epic + 3M 360 Encompass plus a claim/remittance extract. The mechanism is unanswered (Q8, Q11, Q12). Four mechanisms show up in the plan; they are not equally appropriate for 0-to-1.

5.1 Option B1: File extract / SFTP (or secure share) of existing reports

What it is: the client drops the smallest set of files they already produce: Epic Clarity/Caboodle or standard financial reports; 3M 360 Encompass productivity/quality/CMI reports; a denial/remit file onto SFTP or a secure share. SAS (or the client workspace) loads them on a weekly or monthly cadence. Manual load is acceptable for the first two cycles; script the load when the layout stops moving.

This is the product plan’s default 0-to-1 path (§5.2, §5.6, §5.3 “Live FHIR / real-time Epic APIs” deferred).

Tradeoffs: what this makes easy:

• No new vendor API, no App Orchard / FHIR app, no 3M interface project. Inventory of existing reports (Q11) beats new interfaces.
• Matches monthly grain. A trailing six-month Executive/Manager view does not need intra-day CDC.
• Client IT often already operates SFTP for other vendors. Vendor-risk is “file drop,” not “new production interface.”
• Schema can be ugly and still work: the first two cycles are for discovering which columns actually reconcile to the spreadsheet.
• mmmDB is not on the critical path.

Tradeoffs: what this makes hard:

• Layout drift is the operational enemy. A 3M report export that gains a column, or an Epic financial report that changes a filter, silently breaks DNFB. Freshness and schema-drift monitoring are required as soon as refresh is trusted (see §10.4).
• Encounter drill-through (increment 2) needs a row-level extract, not just monthly KPI files. Starting B1 does not prevent that; it does mean increment 2 is a new extract agreement, not a free drill.
• Daily mid-stay refresh (increment 4) on a human file drop will not hold. B1 is sufficient for 0-to-1 and insufficient as the final operational pipeline.
• SAS does not get a stable physical model until someone writes the contract (file names, grains, keys, refresh SLA). Without that contract, every month is a consulting reload.
• Joining Epic A/R unbilled to 3M CMI/CC/MCC to remit denials is still the hard problem. File drop does not magically provide a shared encounter/account key. The extract agreement must name the join keys.

Later-increment fit: right for increment 1. Increment 2 needs row grain in the same files or a companion extract. Increment 4 likely replaces or automates the drop (still files, just scheduled). API-first can be added later; it is not implied.

5.2 Option B2: Direct warehouse access (Clarity / Caboodle / 3M subscription) without a new API product

What it is: still not FHIR. The client grants SAS (or a service principal in the client tenant) read access to Epic Clarity or Caboodle, and/or a 3M 360 Encompass report subscription, and SAS (or client ETL) pulls on a schedule into the dashboard dataset. Physically this may still land as extracts; politically it is “warehouse access,” which the product plan flags as slower than the dashboard build (Epic access is political; Clarity/Caboodle sits with client IT/analytics and a ticket queue).

Tradeoffs: what this makes easy:

• Less re-keying than PDF/Excel report exports. Better chance of stable columns and of encounter keys that actually join.
• A path to increment 2 (row grain) and increment 4 (daily) without changing the political access model: only the schedule and the columns.
• If the client already models DNFB in Caboodle, reconciliation may be “match their model” rather than “parse a finance PDF.”

Tradeoffs: what this makes hard:

• Access is the long pole. A Clarity/Caboodle request can outlast the dashboard. If 0-to-1 is blocked on this, the slice misses its window.
• Broader access increases PHI surface (minimum necessary is harder when the warehouse has everything).
• SAS-written SQL against Caboodle becomes a second metric definition, competing with the HIM spreadsheet: the “numbers rarely agree” problem, now inside SAS’s pipeline.
• Still not an Epic API product. Do not confuse Caboodle read access with App Orchard.

Later-increment fit: good bridge from B1 to daily/row-level if the first client will grant it. Not a 0-to-1 requirement. Prefer existing reports if they already contain the named metrics.

5.3 Option B3: Live Epic / 3M APIs or FHIR

What it is: Epic FHIR (USCDI / App Orchard), Epic proprietary APIs, 3M 360 Encompass interfaces, or intra-day feeds so that coding/CDI refresh “while inpatient” (slide 6).

The product plan defers this: mock-ups are monthly; file drop is faster and sufficient for 0-to-1. Live FHIR / real-time Epic APIs / intra-day 3M refresh are not a v1 must-ship.

Tradeoffs: what this makes easy:

• Increment 4 (daily mid-stay) and any future operational coaching “this week.”
• A story that looks like a modern platform to a software-product buyer. Still overkill for monthly tiles.

Tradeoffs: what this makes hard:

• Calendar time and vendor permissions dominate. App Orchard, FHIR scopes, 3M interface contracts, and client integration engine queues are multi-month even when the dashboard is two pages.
• FHIR resources are a poor native grain for DNFB (gross A/R days unbilled), DNFC clocks, min/chart productivity, and audit accuracy. Those live in revenue-cycle and coding-ops stores, not in USCDI Patient/Encounter. You would still need Clarity/3M extracts for the named 0-to-1 metrics. FHIR does not replace the extract agreement for this product.
• Intra-day pipelines imply streaming or frequent CDC, operational monitoring, and a different PHI volume (increment 4/5 work, not increment 1).
• Choosing B3 as the 0-to-1 path is a one-way delay: you spend the window on interfaces and still have to answer the metric workshop.

Later-increment fit: optional accelerator for increment 4, not a substitute for B1. Do not start Cerner FHIR in parallel (product plan: do not start Cerner in parallel with 0-to-1).

5.4 Option B4: mmmDB (bonus, not a gate)

What it is: Solventum mmmDB, which the deck calls optimal if they will allow. Product plan: do not block 0-to-1 on a vendor-permission long shot; prefer 3M 360 Encompass reports/extracts the client already runs; if the client already has mmmDB, use it as a bonus.

Tradeoffs: richer coding/CDI grain if permitted; permission and contract risk if treated as required. Treating mmmDB as a 0-to-1 gate is a self-inflicted one-way delay. Ask once (Q12); do not design the warehouse around a maybe.

5.5 Ingestion family: comparison

Suggestion (not a stack decision): start from Q11 (what files they already produce) and Q8 (which path is available). Default to B1 into a canonical contract unless B2 is already granted. Hospital 1’s file layout is an adapter input, not the product schema. Do not design 0-to-1 around B3 or B4.

6. Option family C: Tenancy and company shape

Question this family answers: is the running system a single-hospital first deployment of a repeatable product, a full multi-tenant platform on day one, or (now closed) a one-off advisory workspace?

The offer is a resellable product with no to minimal customization. Increment 9 is packaging (entity model, self-onboarding, connector library), not a company-type conversion. Do not pretend 0-to-1 is increment 9. Do not implement 0-to-1 as a workspace that cannot be sold to hospital 2.

6.1 Option C1: Single-pilot analytics workspace

What it is: one facility, one set of extracts mapped into the canonical contract, one workspace (client tenant or SAS-operated) that is a deployment of the product, not a unique consulting file. No entity resolution across hospitals on day one. No customer self-onboarding. No pooled peer benchmarks.

This is still the product plan’s 0-to-1 deployment grain (§5.1, suggestion 13: one facility even inside a system). Under the resale goal, C1 without a portable catalog is not this option. That is a discarded advisory one-off.

Tradeoffs: what this makes easy:

• Avoids master data (health system → facility → service line → provider → coder), which is “where these products die.”
• Definition workshop has one HIM/CFO to sign. Multi-hospital roll-up hides broken definitions.
• Security questionnaire, BAA, and extract request are for one client.
• Matches the mock-ups (one period, one facility story).

Tradeoffs: what this makes hard:

• A second hospital is a copy-and-modify, not a tenant switch, unless the metric catalog and extract contract were designed to travel, which the resale goal now requires.
• SAS’s IP can leak into a client-specific Power BI file (see A1 tax). That leak fails increment 1; it is not a later cleanup.
• Internal demo / second engagement cannot share production data (and should not).

Later-increment fit: correct for increment 1 deployment (one facility) if and only if catalog + adapter travel. Increment 9 is packaging on top of that, not a rewrite.

6.2 Option C2: Multi-tenant product platform from day one

What it is: orgs, tenant isolation, connector library, self-onboarding, possibly pooled de-identified benchmarks, SAS-branded login. Increment 9 brought forward.

Tradeoffs: what this makes easy:

• Engineering time goes into tenant isolation, self-onboarding, and a connector library (the thing increment 9 is for). The resale goal does not require that on day one.
• Isolation, authz, and audit are designed once.

Tradeoffs: what this makes hard:

• Directly contradicts the 0-to-1 deployment grain (one facility first, not self-serve multi-tenant). The offer is a product; the first ship is still not increment 9.
• Requires answers SAS does not have: named pilot, BAA pattern, security bar (SOC 2 / HITRUST / region), pricing, entity model, legal right to pool metrics.
• Boils the ocean with four focus areas × many source systems × three view levels (the primary delivery risk in the product plan).
• No customer data in the repo; a multi-tenant platform with synthetic tiles is another mock-up.
• SSO, customer self-onboarding, and multi-tenant SaaS hardening are explicitly deferred.

Later-increment fit: destination packaging for the resale goal. Not a 0-to-1 option. Starting C2 is a one-way spend of the 0-to-1 window (you still need a catalog and a first hospital).

6.3 Option C3: Repeatable product, first hospital now, packaging later

What it is: the path the resale goal actually requires. Deliver C1 as a deployment with portable artifacts (versioned SAS-owned metric catalog, canonical extract contract, parameterized load, definition one-pagers, configuration-vs-customization boundary). Hospital 2 is adapter + config. After two hospitals prove the catalog, wrap A2/A3 and C2 as packaging (product plan increment 9).

The offer is a product. Sequence is deployment grain (one hospital first) vs platform packaging (increment 9).

Tradeoffs: what this makes easy:

• Protects the 0-to-1 window (live numbers at hospital 1) without pretending increment 9 has shipped.
• Makes A1 acceptable only as a skin: the BI tool is disposable if the catalog is not.
• Aligns with “production-ready is a sequence” (vision and roadmap; 0-to-1 plan) and with no-to-minimal customization.

Tradeoffs: what this makes hard:

• Requires discipline the first client will not give you for free: no one-off measures in the BI file, no facility-specific denial formula (a mapping table is fine), no undocumented Excel steps.
• Product Owner owns catalog delivery; the first hospital still must not get one-off measures.
• First-hospital customization pressure is the operational risk (0-to-1 plan). A loved one-off is a failed 0-to-1.

Later-increment fit: the required family under the current offer. C2 remains increment 9. A consulting one-off is out.

6.4 Tenancy family: comparison

Suggestion (not a stack decision): do not implement C2 as 0-to-1. Implement C1 as C3: one facility, SAS-owned catalog, canonical extract, configuration not forks. The portable catalog is the 0-to-1 architecture constraint.

7. Cross-cutting layers (options inside any family)

These are not a fourth “stack pick.” They are layers every honest option still has to place somewhere. Placement is a technical direction choice; the product is not.

7.1 Semantic / metric catalog vs dashboard-only formulas

Product plan §12 names a versioned metric catalog as a production destination (“one agreed calculation” with change history). Increment 5: metric-definition versioning so a formula change does not silently rewrite history. Several of those controls must start in increment 1 as soon as real data is used.

Suggestion (not a stack decision): keep definitions in SAS-owned signed one-pagers plus a machine-readable catalog (even a versioned YAML/SQL folder in git) rather than only in a BI measure. Under the resale goal this is required in increment 1, not a later hedge. Waiting until “we are a product” is how silos reappear inside SAS’s own tool and how hospital 2 becomes a rebuild (product plan suggestion 2).

Do not fill the catalog with invented formulas. The workshop fills the 0-to-1 plan’s metric questions for catalog v1. SAS owns the catalog; hospitals own configuration.

7.2 Warehouse vs BI import vs files-as-source

A warehouse is not the product. The join of Epic unbilled + 3M severity + remit denials at facility-month grain (0-to-1) or encounter grain (increment 2) is the product’s data problem.

7.3 Identity and access

Authz by role is a production destination (vision and roadmap). For 0-to-1, two named audiences and a shared extract are enough if the hospital sends aggregate-only KPIs. If it sends row-level encounter data, least privilege and access logging move from destination to day one.

8. One-way door vs incremental / reversible

Bezos’s metaphor, applied here: a one-way door is expensive or legally messy to undo (data copies, contracts, company type, trust). An incremental decision can be reversed or layered after the first trusted monthly view. Classification is about reversibility, not about importance. A reversible decision can still be urgent.

8.1 Company / offer shape

Classification: one-way to treat as a consulting one-off. The offer is a resellable product with no to minimal customization. Implementing a unique advisory workspace (forked measures, unique layout) is a one-way door against that offer. Implementing C2 (full multi-tenant platform) on day one is a different one-way door: it spends the window on packaging before hospital 1 trusts a number.

Incremental: C3: one-facility deployment with a SAS-owned catalog, canonical extract, and configuration-vs-customization boundary. Hospital 2 is adapter + config. Increment 9 packaging can wait.

Hosting (0-to-1 plan question 9) and BI vs custom app remain choosable. Forking hospital 1’s formulas is not. Going back to per-hospital consulting dashboards would be a commercial and technical reset.

8.2 Who hosts PHI, and whether a BAA is required

Classification: one-way door.

Why: the moment SAS receives or stores PHI or a limited data set without a BAA, that is a legal event, not a refactor. Copies persist (SFTP disks, BI caches, email, laptops, backup). Switching from SAS-hosted to client-tenant later means proving deletion; switching the other way restarts vendor-risk. Counsel, not engineering, closes this. This document classifies it; it cannot close it. There is no named pilot and no BAA in-repo.

Aggregate-only KPIs (if counsel agrees they are not PHI) shrink the door but do not remove it: facility-level extracts with dates of service can still be PHI or a limited data set. Whether the hospital sends aggregates or encounter rows is an open question; “monthly dashboard” is not an answer.

8.3 Identity / security minimum

Classification: mixed. Some incremental, some one-way for a given client.

8.4 Warehouse / metric catalog vs dashboard-only formulas

Classification: required in increment 1 (resale goal); one-way after the first hospital’s trusted numbers if the catalog was skipped.

Why: the first load can be a BI import. After the CFO has accepted a DNFB tile, that measure is the definition in practice. Changing it rewrites history unless versioned (increment 5 requirement, needed as soon as real data is used). Two diverging pilots make harvest into a catalog a rewrite.

Suggestion: take the incremental door now (external versioned catalog, even if the viz is Power BI). Waiting is how the door swings shut.

8.5 Extract contract vs API-first (Q8, Q11)

Classification: extract-first is incremental; API-first as 0-to-1 is a one-way delay.

Why: B1→B2→automated drop→optional B3 is a legal sequence (increments 1, 2, 4). Starting on FHIR/App Orchard spends the window and still needs the extract fields FHIR does not have (DNFB clocks, min/chart, audit samples).

The extract schema becomes sticky: once SAS and the client reconcile to a file layout, changing keys (account vs encounter vs CSN vs medical record) is a one-way-ish data-model door. Write the join keys down in the extract agreement. That is still not an API-first decision.

8.6 BI tool vs custom app (family A)

Classification: incremental if the catalog and conformed model sit outside the viz layer; one-way if the product is the BI file or the app codebase.

A1→A2 is a republish. A2→A3 is a new skin on the same catalog. A3 as the first artifact, with formulas in route handlers, is a one-way custom-app bet. Product plan suggestion 3: do not deliver 0-to-1 as a one-off client-tenant file; a branded app is packaging after the catalog is copyable, not a fake-data rebuild.

8.7 Later adapters (explicitly incremental)

These are sequenced in docs/planning/product-vision-and-roadmap.md. None should be treated as 0-to-1 architecture constraints. None require throwing away a working monthly Executive + Acute Care Coding pair if grain and catalog were honest.

8.8 Classification summary

9. Questions that must be answered to fine-tune technical direction

These are distinct from beachhead decisions (Executive + Acute Care Coding; Epic + 3M) and from SAS staffing facts. Numbering follows the 0-to-1 plan. T-n items are extra technical questions, not metric formulas.

The product is a resellable product with no to minimal per-hospital customization. First deployment is one Epic + 3M facility (decision B). Multi-tenant self-serve packaging is increment 9. SAS owns the catalog (Product Owner owns delivery); hospitals own configuration. Technical Owner is SAS privacy/security owner. SAS waits until a hospital pilot is selected.

9.1 SAS: buyer, pricing, configuration policy

1. Q1. Economic buyer: CFO, VP Revenue Cycle, HIM, or SAS’s own consulting delivery team? (Affects who must log in, therefore identity placement.)
2. Q2. Once a pilot is named, what should be true in 6 months: a live product with a first hospital’s numbers and a credible hospital-2 path? (A branded-demo build is out.)
3. Q4. Priced as what: pilot fee or software subscription? An unscoped engagement add-on that implies per-hospital build conflicts with resale.

T-1b. What is the written list of allowed configuration keys (targets, maps, facility ids, calendar) vs a product-change request vs a no-fit?

9.2 Hospital: hosting, data path, and security

The hospital must answer. SAS cannot decide these alone. They close option families A and B.

1. Q6. Who is the first hospital, and do they run Epic + 3M 360 Encompass today?
2. Q9. 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. Q10. Is a BAA in place or startable now? What is the vendor-security questionnaire timeline?
6. Q8. What data-sharing path is available: SFTP of existing reports, Epic Clarity/Caboodle access, 3M report subscription, mmmDB, something else?
7. Q11. 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. Q12. Will mmmDB be allowed, or is that off the table? (Bonus, not a gate.)
11. Q23. What is the minimum security bar the first hospital will require (MFA, SSO, SOC 2, HITRUST, hosting region)?
12. Q24. Aggregate-only KPIs vs row-level encounter data: which will the hospital actually send?
13. What is the actual file grain they will send: facility-month aggregates, encounter-level limited data set, or mixed?

T-7. After counsel reviews the actual file (not the mock-up), is the 0-to-1 payload de-identified, a limited data set, or PHI? Engineering cannot declare this from “monthly dashboard.”
T-8. Retention and exit: how long may SAS keep extracts, and what is the deletion procedure if the numbers cannot be reconciled in two cycles?

T-9. Is encryption in transit/at rest, access logging, and backup already on the questionnaire even for a file drop into a hospital-tenant workspace (SAS as guest) or only for SAS-hosted systems?
T-10. Are SAS laptops / email in scope if an analyst opens the extract to debug a DNFB mismatch? (They usually are. This is an endpoint and DLP question, not a BI-tool question.)

9.6 Questions that do not choose among option families

• Quality-TBD, Profee, and encounter worklist are out of 0-to-1. They are not stack inputs until the vision/roadmap questions reopen them.
• Peer benchmarks stay out until SAS has a real source.
• Metric numerators belong in the workshop before formulas are coded. They fill catalog v1; they do not choose A1 vs A3.
• Market-share figures, Iodine, and Quality copy on the customer deck are sales-collateral questions in the vision and roadmap, not hosting choices.

10. Other technical information the stack choice depends on

10.1 PHI, limited data set, aggregate-only

Known risk (0-to-1 plan): encounter detail, and even facility-level extracts with dates of service, can be PHI or a limited data set. Advisory firms hosting this without a BAA, minimum necessary, and access logging are in legal risk from the first real file. Monthly KPIs might be de-identified aggregates. That is a question for counsel (Q24, T-7), not an assumption.

Implications for every option family:

• A1 + aggregate files that counsel agrees are not PHI: smallest SAS legal surface. Still apply minimum necessary; do not take extra columns “for later encounter drill.”
• A1 + SAS receives LDS/PHI to build the dataset: BAA may still be required even though the BI workspace is the client’s. T-2 exists for this reason.
• A2/A3: treat as PHI hosting until counsel says otherwise. Encryption in transit and at rest, named-user access, access logs, backup/restore start with the first real file (increment 1 controls, increment 5 evidence).
• Increment 2 (encounter rows, chart identifiers, work queues) is a different PHI regime than increment 1 monthly tiles. Designing increment 1 extracts with extra identifiers “to make drill easy later” can accidentally pull increment 2 PHI into increment 1. Prefer a new extract agreement at increment 2 over over-collecting now.
• Peer-benchmark pooling (increment 9) requires a legal right to de-identify and pool. Showing “peer median” without that right is a credibility and possibly contractual problem, not a BI feature flag.

This evaluation is not a HIPAA policy. It records that stack choice is downstream of Q9/Q10/Q24/T-7.

10.2 Increment 1 vs later increments (grain, sources, surfaces)

Technical consequence: 0-to-1 is an OLAP / monthly fact problem, not an operational worklist problem and not a FHIR problem. Stacks optimized for intra-day encounter workflow (custom app + FHIR + row-level authz) optimize the wrong increment. Stacks that cannot later add a row grain (pure KPI files with no key) block increment 2. The hedge is: monthly facts and documented keys, without shipping the worklist.

10.3 Metric-definition versioning (so a formula change does not silently rewrite history)

Known destination (vision and roadmap, increment 5 and production-ready): a versioned metric catalog with change history; who approves a formula change is operational ownership.

Why it belongs in a stack evaluation:

• DNFB and DNFC are notorious for site-specific clocks. If SAS publishes “one agreed calculation” a CFO does not recognize, trust dies (§8.2).
• Denial split is a mapping project, not a vendor field. Wrong mapping produces a confident, wrong executive chart: the silo problem recreated.
• Grouper version (MS-DRG vs APR-DRG, which 3M grouper) is a dimension of CMI, not a constant.
• A BI measure that always computes “current logic over all historical months” will rewrite March when the September workshop changes an exclusion.

Minimum technical pattern (suggestion, not a formula spec):

• Each named 0-to-1 metric has an id, version, effective dating, owner, and source fields as agreed in the workshop.
• Loads store the metric version used alongside the published value (or store the conformed facts such that a version can be recomputed).
• Changing a definition is a change-controlled new version, not an edit in place.
• History already shown to the CFO is either frozen or explicitly restated.

Do not code numerators here. The 0-to-1 plan’s workshop questions stay open.

10.4 Extract freshness and monitoring

Known: weekly or monthly refresh; manual acceptable for first two cycles; script when layout stops moving. Increment 5: monitoring of extract freshness. Operational ownership: who is paged when the extract is late; who approves a formula change.

0-to-1 bar (suggestion): even a manual SFTP drop needs a written check: file arrived, row count vs last month, schema (column names) unchanged, join key uniqueness, and “does DNFB match the client spreadsheet within agreed tolerance.” That can be a checklist before it is a pager. Once the tile is trusted, an undetected missed drop is worse than a late spreadsheet. Leaders will have acted.

Increment 4 bar: automated extract, freshness SLO, schema-drift alerts. Not day one.

10.5 Authorization by role

Slide 9 roles: CFO / VP Revenue Cycle; HIM / Coding Director; CDI Director; Quality / Compliance. 0-to-1 only must serve the first two for the two mocked views. CDI Director gets executive tiles (CMI, CC/MCC), not their own dashboard until increment 3. Quality is TBD.

0-to-1: two reports or two workspace roles is enough. Shared extracts underneath so the CFO’s DNFB/CMI/denials and the HIM director’s DNFC/productivity/quality are one story.

Increment 2: row-level access, break-glass, and “minimum necessary” on account identifiers. Suggestion from the product plan: read-only reconciling list, not a workflow app that assigns queues.

Destination: access control by role matching slide 9, with MFA and, for hosted PHI, a BAA and audit logs.

Do not design coder work-queue permissions in the 0-to-1 stack. That is how encounter worklist sneaks in as a “small add.”

10.6 What production-ready will eventually require (destination, not day-one scope)

When SAS is ready to call a deployment production-ready, the vision-and-roadmap destination is:

• A versioned metric catalog with change history.
• Connectors at least for Epic (or its warehouse) and Solventum 3M 360 Encompass, with a written adapter pattern for the next EMR and the next CAC/CDI tool.
• Three view levels that reconcile: executive ↔ manager ↔ encounter.
• Acute + CDI manager surfaces; Profee and Quality only if the offer questions are yes.
• Access control by role matching slide 9, with MFA and, for hosted PHI, a BAA and audit logs.
• Freshness that matches the decision: monthly is enough for CFO trend; “coach this week” needs at least daily DNFC/productivity.
• Operational ownership (who is paged when the extract is late; who approves a formula change).

Increment 5 adds: HIPAA/BAA if not already in place the moment PHI moved; audit logs; encryption in transit/at rest; named-user access with MFA; backup/restore; environment separation; metric-definition versioning; extract freshness monitoring. These are not optional if real patient or even limited-data-set rows exist; several must start in increment 1 as soon as real data is used. What waits is hardening and evidence (policies, pen-test, SSO, uptime target), not the first BAA.

None of that is required to prove the thesis. The thesis is proved when one CFO and one HIM director stop waiting on a spreadsheet for the named mid-cycle metrics.

Adapter pattern (destination sketch, not a 0-to-1 build): one conformed facility-month (later encounter) model; per-source adapters that only map keys and fields into that model; metric catalog reads the conformed model, not Epic or 3M natively. That is how increment 7 (Cerner) does not fork the dashboards. Writing Cerner mappings now is out of scope.

10.7 Logical architecture (stack-agnostic)

Every option family still has these layers. Vendors are not assigned.

This diagram is a constraint, not a product pick. A1, A2, and A3 all implement it; they differ in who hosts which box.

10.8 What cannot be built yet (even though it is technical)

Until Q6 names a pilot and Q8/Q11 produce files:

• No production SQL, no Clarity/Caboodle spec, no 3M extract spec, no FHIR mapping written as if access exists.
• No metric formula catalog.
• No environment that holds real PHI.

Until Q9/Q23:

• No honest hosting account, no IdP decision, no SOC 2 project as the 0-to-1 path. The catalog and canonical extract are in scope regardless.

The product plan’s 30-day path if a pilot can be named: metric workshop, extract inventory, BAA/security started, file layouts in a folder, with no UI work beyond sketching the two mock-up views onto agreed metrics. If no pilot is selected: wait. Do not staff a UI. The deck stays sales collateral.

11. Conditional direction (suggestions only)

The offer is a resellable product. These are if/then hedges on the open questions, not “the stack.” A row that would rebuild a unique dashboard per hospital is out.

The table above is the full if/then set. The diagram is only the hosting fork and the no-pilot gate.

Power BI is cited as a common A1 skin, not as a signed-off tool. Tableau, Looker, or a later custom app are the same family if they sit on the SAS catalog. The resale goal does not pick among them; it forbids a unique, non-copyable workspace.

12. How this evaluation stays grounded

End of evaluation. Option families are analysis. Open questions in §9 stay open until SAS leadership and the first hospital answer them. No stack in this document is a decision.