RCM Insights data setup - what the app needs before any answer can be trusted
Objective. Describe, at app-logic level, what RCM Insights depends on to produce answers a customer can stand behind: the data and signals it draws on, the setup, config and integrations it needs, the apps it leans on, and what a CSM validates before trusting a number. Specifics are 'confirm with product'; the goal is to know what questions to ask, not to assert an integration spec.
RCM Insights is only as good as the data, definitions and scope behind its answers. This reference lays out what the app needs to generate trustworthy answers - without inventing connectors or refresh cadences. It names the dependencies, the setup areas, the upstream apps, and the validation a CSM runs so a fluent answer is backed by real coverage, agreed definitions and correct role scope.
See it in the demo
The data and signals it depends on
RCM Insights answers questions across the account's revenue-cycle and operational data, so the quality of every answer rests on what feeds it:
- Source data - the revenue-cycle and operational records the questions are asked against (claims, denials, AR, payer, client and operational activity). Which sources are actually connected is customer-specific - confirm with product.
- Coverage - how much of the relevant population each source covers. A source can be connected but cover only a slice of payers or a short period. Presence of a source is not coverage.
- Freshness - how current each feed is. A freshness timestamp tells you how stale an answer may be.
- Metric definitions - what each number counts, over what population and period, with what exclusions. The definition governs whether any two figures are comparable.
- Role and scope signals - who is allowed to see what, so an answer respects the viewer's permitted scope.
The Data and Metrics surfaces exist precisely to expose these so a user can inspect them - that inspection is the point of the product.
Setup, config and integrations required
Described at app-logic level - treat every specific as 'confirm with product':
- Source connections - the relevant revenue-cycle and operational data has to be connected and kept refreshed. Which sources, how they connect and the refresh cadence are customer- and entitlement-specific.
- Metric definitions configured and agreed - the definitions the answers use should be set to match the customer's own definitions, not left at a default. Pinning these early is what prevents definition drift.
- Role scope and sign-in - the Admin and role sign-in areas govern who can ask what and see what. Role scope must be set so answers respect permissions.
- The askable surface - Discover helps users find what is askable; the quality of that depends on the connected data and definitions behind it.
Do not assert specific connectors, APIs, authentication methods, refresh intervals or security controls. Name the area, say it is configurable, and route the specifics to product and the implementation specialist.
Dependencies on other apps
RCM Insights is the question-and-evidence layer; the operational substance comes from the broader platform:
- RCM Operations - prioritises which issue to address and frames the action. Insights lets a user ask open questions across the same data with inspectable evidence; the two share the discipline that an answer or signal is only as good as the data behind it.
- Work Output / Work Understanding - supply completed-work, quality, cost and process signals that many business questions draw on.
- Value Leakage - supplies the recoverable-value framing, where capacity value and cash must stay separate.
Which of these are in scope for a given customer is entitlement-specific. The practical point: an Insights answer can only be as rich as the upstream data that is connected and defined - confirm the scope with product rather than assuming the full platform is feeding it.
What a CSM validates before trusting the numbers
Before any answer is relied on or repeated, a CSM validates four things for the account - confirmed with product:
- Sources connected - which revenue-cycle and operational sources actually feed the questions users ask.
- Coverage - that the connected sources genuinely cover the relevant population, not just a slice. A listed source is not proof of coverage.
- Freshness - the real refresh cadence, so staleness is known and factored in.
- Metric definitions and role scope - that the definitions are the customer's own and agreed, and that role scope correctly limits who sees what.
This is the same discipline the workflow modules teach at screen level: the Data view establishes coverage and freshness, the Metrics view establishes comparability. The CSM's validation is confirming these hold for the real account, not just the seeded demo.
What to escalate to the implementation specialist
Escalate - never guess - on:
- Exact source connectors, APIs and authentication - how a specific system is integrated and secured.
- Refresh cadence and data pipeline specifics - the real latency and scheduling of each feed.
- Security, compliance and data-residency specifics - never asserted by Sales or CSM; these always go to product and security.
- Metric definition formulas - the exact numerator, denominator, inclusions and exclusions of a metric, when precision matters for an external commitment.
- Role model and permission edge cases - how scope is enforced for unusual org structures.
The honest line to a customer: the ask-and-inspect model is real and demo-shown; which sources are live, how fresh they are, exactly what each metric means and how role scope is enforced for your account are confirmed with product and set up with the implementation specialist.
Interpretation check
An RCM Insights answer is only as good as the data, definitions and scope behind it. A listed source is not coverage; a freshness timestamp tells you how stale an answer may be; a metric definition governs whether a number is comparable. Which sources are live, their coverage and cadence, the metric definitions and role scope are customer-specific - confirm with product, escalate security and integration specifics.
In the field
KnackGlobal (RCM): before any AR-days or denial figure from Insights is repeated to the client, the CSM confirms with product which payer and claims sources are connected, how much of the payer population they cover and how fresh they are - because a figure built on partial coverage, repeated under displacement pressure, is the kind of error that threatens a large contract.
Practical task
For a sample or real account, write a data-setup readiness note: list the four things a CSM validates (sources connected, coverage, freshness, metric definitions and role scope), mark each as confirmed / pending / confirm-with-product, and write the exact escalation question you would send the implementation specialist for the two riskiest unknowns. Do not assert any connector, cadence or security control you have not confirmed.
Self-check
A feed is listed as connected. Can a CSM trust answers built on it?
Not yet - presence of a source is not coverage. The CSM validates that the source genuinely covers the relevant population and how fresh it is, confirmed with product, before trusting answers built on it.
Which specifics must never be asserted by Sales or CSM and always go to product or the implementation specialist?
Exact connectors, APIs and authentication; real refresh cadence and pipeline latency; security, compliance and data-residency specifics; exact metric formulas; and role-model edge cases. Name the area, confirm with product, escalate security and integration detail.
Why must metric definitions be configured to the customer's own, not left at a default?
Because a metric definition governs whether a number is comparable. A default definition that silently differs from the customer's causes the worst reporting errors; pinning the customer's definitions early prevents definition drift.
How does RCM Insights depend on the rest of the platform?
It is the question-and-evidence layer; the operational substance comes from upstream apps (RCM Operations, Work Output, Work Understanding, Value Leakage). An answer is only as rich as the upstream data connected and defined for that customer - confirm scope with product.
Verified vs demo. The Data, Metrics, Discover and Admin surfaces and the ask-and-inspect evidence model are demo-shown on seeded data. The live connected sources, their true coverage, the real refresh cadence, exact metric definitions, role-scope enforcement and all security and integration specifics are customer- and entitlement-specific - confirm with product and the implementation specialist.