> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/platform-overview/shared-context-and-applications.md). # 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
The data platform retains evidence and produces shared views. Change events notify applications. Applications also read scoped views directly and publish observations and outcomes back. Each application owns its work and transactions.

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](/platform-overview/how-it-works.md) for that action boundary. ## Follow One Handoff In the integration pattern illustrated by [One Patient, Two Workflows](/data/patient-context-walkthrough.md), 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](/agent/platform-functions.md). 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](/data/connect-another-workflow.md), then record the evidence in the [Technical Evaluation Packet](/platform-overview/evaluation-packet.md). ## Continue by Task * **Understand the patient story:** [One Patient, Two Workflows](/data/patient-context-walkthrough.md). * **Inspect data semantics:** [World Model](/data/world-model.md), including source evidence, time, confidence, and projections. * **Assign operating owners:** [Operating Model](/platform-overview/operating-model.md). * **Implement a supported interface:** [Developer Guide](https://docs.concurrence.com/developer-guide). This map does not define a universal event API. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/platform-overview/shared-context-and-applications.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.