Operating Model

How clinical, operational, data, engineering, and Concurrence teams divide responsibility for a deployed workflow and its ongoing improvement.

A healthcare application deployment spans several owners. The team defining the workflow may not control the source records, scheduling system, communication channel, or people handling exceptions. The operating model connects those responsibilities so an interaction can become completed work.

Start with one bounded workflow and name the people who can make its decisions. The responsibilities below are a planning model; the actual implementation and support commitments belong in the deployment agreement.

Define the Outcome Before the Agent

For an appointment-change workflow, specify the starting condition, eligible population, permitted changes, required verification, and evidence of completion. Decide what happens when the patient cannot be identified, the external system is unavailable, or the result is ambiguous.

The workflow owner defines success in operational terms. Clinical leaders define clinically consequential boundaries and the evaluation criteria for those boundaries. Engineers translate those decisions into data access, tools, authored configuration, and tests.

An outcome definition can be written before every integration is available. It gives the implementation team a concrete target and exposes which missing data or authority prevents the workflow from reaching it.

Assign Decision Rights

Area	Organization's decision	Platform and implementation work
Workflow scope	Which work is eligible, what completion means, and what stays with a person	Map that scope into agent guidance, Context Graph states, tools, and handoffs
Clinical and operational policy	Verification requirements, permitted actions, escalation boundaries, and review criteria	Make the policy inspectable in configuration; implement the applicable enforced controls and tests
Data and integration	Authorized sources, usable identifiers, freshness needs, and external-system permissions	Configure supported ingestion, mappings, retrieval, write-back, and reconciliation
Messaging	Sending brand, recipient consent evidence, message purpose, and follow-up ownership	Concurrence-managed provisioning and registration where required; configured routing and delivery handling
Live operations	Staffing, operating hours, who receives exceptions, and how unresolved work is closed	Configure and exercise supported monitoring, operator controls, and transfer paths
Measurement	Baseline, outcome definitions, relevant segments, and acceptable trade-offs	Configure available evaluations and reporting; connect external outcome evidence where needed
Release	Who can accept the evidence and authorize a change	Prepare reviewed configuration, targeted validation, rollout, and recovery procedures
Data governance	Access, residency, retention, and the intended recipients of shared data	Provision the agreed controls and verify actual access and evidence coverage

The same person can own several areas in a small deployment. Name an accountable owner for each outcome and the teams that contribute to it. Record who can approve scope changes, stop a workflow, and accept unresolved risk. A platform permission grants an operation; the organization's policy determines when its use is appropriate.

Separate Live Work from Improvement Work

Live operations handles the patient interaction and its immediate exceptions. Operators need enough context to act, a supported way to intervene, and a destination for work that cannot finish during the interaction. An escalation instruction is useful only if the relevant person or fallback is reachable.

Improvement work changes the system that handles future interactions. The team reviews patterns, forms a hypothesis, authors a candidate, and validates it before release. It can improve a source mapping, a tool, a workflow, or a measure as well as an agent instruction.

The arrows describe team work. Analytics, simulations, and version sets supply supporting capabilities; they do not autonomously approve, promote, or roll back a change.

Plan the Handoffs That Usually Cross Teams

Source Data to Workflow

Agree on the identifiers and source records required for an eligible case. Inspect representative joins before launching the interaction: can the intended person, appointment, practitioner, and location be found? Record the expected freshness and the fallback for missing or conflicting data.

A successful connector sync establishes only what that connector's result reports. It is not proof that every relationship needed by the workflow is available to the agent. See Connectors and EHR.

Keep source availability, mapping quality, and consumer readiness distinct in the operating agreement. Assign the team that can investigate each failure and one owner who coordinates resolution across the complete workflow.

Application to Application

Name the producer and consumer owners, the meaning of the shared evidence, and the criteria for the receiving application to act. Assign ownership of schemas, identity corrections, freshness, duplicate triggers, and recovery. Each application retains its own task state; the data team does not implicitly own unfinished business work.

For a second workflow, identify the workflow buyer or sponsor, the operating owner, and the data or IT owner together. Confirm reuse, new permissions, action authority, and acceptance evidence using Connect Another Workflow. Shared access does not replace a review of the new purpose or recipient.

Agent to Operator

Define the reason for handoff, the context the operator needs, and what happens if no operator answers. Test the applicable listen, takeover, handback, or external-transfer path. Those controls have different behavior and availability across channels. See Operators and Escalation.

Platform to External System

Agree on what confirms an external action and who reconciles an ambiguous result. Preserve the identifiers needed to find the original request and destination record. Repeating a non-idempotent action is a business decision as well as an integration concern.

Define support hours, severity criteria, notification and escalation routes, and recovery expectations in the deployment agreement. Exercise the handoff with a representative failure before launch so the responsible teams can find the evidence and act on it.

Evidence to Release Decision

Give the reviewer the candidate configuration, the relevant tests, known gaps, and the intended outcome comparison. Include associated integration or service-setting changes that are outside the pinned agent and Context Graph versions. Deployment Model explains how those selections take effect.

Establish a Review Rhythm

Use a review cadence appropriate to the workflow's volume and consequences. Start with unresolved work, failed or ambiguous external actions, missing evidence, and representative patient interactions. Compare outcome measures using the same definitions and relevant segments.

Assign each investigation to the team that can change the relevant part of the system. A drop in completion could begin in source data, delivery, staffing, a tool, or agent behavior. Preserve confirmed failure cases in the test set so the next change can be evaluated against them.

For the evidence to request during a technical review, continue with Evaluating Concurrence. For the recurring engineering workflow, see Continuous Improvement.