Shared Context and Applications

How shared patient context, change events, and specialized applications work together without sharing one transaction or one set of permissions.

Concurrence connects useful healthcare applications through a persistent data foundation. With the appropriate publication integrations, a clinician-reviewed note, a patient conversation, and a scheduling result can contribute different evidence about the same patient. The next authorized application can use that context instead of reconstructing the history from scratch.

The Health World Model is a time-aware representation of entities, relationships, observations, and current state. It records what the organization knows from connected sources, including gaps and disagreements. It is not a claim to a complete patient record or a model that independently predicts disease progression.

Three Parts, Different Responsibilities

Read context, receive changes, and publish outcomes are different interactions. This is an ownership map, not one atomic transaction.

Part	What it owns	What a consumer must still check
Data platform	Source evidence, entity identity, reconciliation, and reusable views	Relevant source coverage, provenance, access, and freshness
Change events	Communication between producers and interested consumers	The selected interface's delivery, ordering, replay, and recovery contract
Transactional applications	Sessions, drafts, tasks, approvals, decisions, and actions	Their own business rules, authoritative state, and evidence of completion

Scribe owns recording and note review. An outreach application owns contact attempts and delivery handling. A follow-up application owns its task and scheduling request. Shared context connects these applications; it does not replace their operational state.

The external system retains authority over the records it owns. A scheduling request is not a confirmed appointment until the target supplies the required confirmation. See How It Works for that action boundary.

Follow One Handoff

In the integration pattern illustrated by One Patient, Two Workflows, a clinician approves a care-team check-in. A configured publisher contributes the reviewed Scribe instruction with its patient and source references. The data platform connects it to the patient's history. The follow-up application reads that context, checks eligibility and current availability, and requests a booking. Confirmation becomes evidence for later work.

This example assumes separately configured publication and follow-up integrations. Finalizing a Scribe note does not itself publish a world-model observation or start follow-up work. Verify the selected integration's mapping, access, trigger, and recovery behavior before relying on the handoff.

Each handoff needs an owner and an observable result:

1. Publish: identify the patient, source, relevant times, and reviewed instruction.
2. Read: verify the required evidence is available to the consumer and fresh enough for its decision.
3. Act: apply the receiving application's permissions, review policy, and transaction rules.
4. Reconcile: distinguish a proposal, an attempted action, and a source-confirmed outcome.

An event can tell an application that something changed before its shared view is updated. A received event does not establish that every consumer finished processing it. If two applications must not perform conflicting actions, enforce that rule in the authoritative service at the point of mutation. A notification alone is not a lock.

What Carries Forward

The reusable foundation includes authorized source connections, entity mappings, source-linked observations, data definitions, and suitable platform functions. Reuse does not require all applications to use the same prompts, interface, or decision rules.

For example, a clinician may inspect the full evidence behind a reviewed instruction while an outreach task uses only the patient reference, permitted contact details, and approved next step. A population query needs its own cohort definition, consistent units and codes, and explicit handling of missing records. A shared patient view alone does not establish a valid clinical comparison.

Shared infrastructure also does not mean shared visibility across customers. Each recipient needs an authorized purpose and access scope. Reading patient context does not grant permission to write to an EHR, send a message, or use it for a different purpose.

Choose the Right Integration Boundary

A direct source lookup is useful when a decision needs an authoritative current value, such as a bookable slot. Shared context is useful when work needs continuity across sessions, evidence from several sources, correction history, or reuse by another application. A workflow can use both: shared history for context and a live source check before acting.

Do not measure platform reuse by the number of connected applications alone. Measure whether the next workflow reaches an accepted outcome with less incremental setup, while retaining the necessary access and recovery controls. Start with Connect Another Workflow, then record the evidence in the Technical Evaluation Packet.

Continue by Task

• Understand the patient story: One Patient, Two Workflows.
• Inspect data semantics: World Model, including source evidence, time, confidence, and projections.
• Assign operating owners: Operating Model.
• Implement a supported interface: Developer Guide. This map does not define a universal event API.