> 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/data/patient-context-walkthrough.md).
# One Patient, Two Workflows
Follow one patient's source records into a clinician-reviewed note, a follow-up workflow, and a confirmed scheduling outcome.
A new application starts with useful context when patient identity, source history, and reviewed observations carry forward from earlier work. Follow Alex Morgan from a prescription through a clinician-reviewed note to a completed follow-up task.
Use the tabs to follow the patient story, inspect source evidence, and review application ownership and reuse.
{% hint style="info" %}
Alex, the records, and the timestamps are illustrative. The downloadable file describes the walkthrough; it is not a Platform API payload or a measured latency result.
The case 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. The implementation team must establish those mappings, permissions, triggers, and recovery paths.
{% endhint %}
{% tabs %}
{% tab title="Patient story" %}
### How the Record Grows
1. **Prescription, April 6.** An EHR contributes an active blood-pressure prescription. Its source and observation time remain attached to the record. A prescription establishes what was prescribed; it does not establish what Alex took.
2. **Patient report, April 9.** Alex says, "I have skipped a few doses. I have also felt dizzy. Afternoon calls work best for me." Reported use, symptoms, and contact preference join the same history. They remain distinguishable from the prescription.
3. **Measurements, April 10.** An authorized monitoring feed contributes two blood-pressure observations with dates and units. The clinician can inspect them alongside the prescription and conversation. The record does not infer that the medication caused the dizziness.
4. **Reviewed note, April 10.** The clinician reviews the evidence and approves a care-team check-in. Scribe owns the note and review workflow. The configured publication integration contributes the approved instruction as shared context for the next application. No medication change is authorized in this case.
5. **Follow-up request, April 10.** The follow-up application uses the patient reference, reviewed instruction, and afternoon contact preference. It checks current scheduling availability; Alex selects April 11 at 14:30 UTC. The request is submitted and the task remains pending.
6. **Confirmed result, April 10.** The scheduling system confirms the appointment. A read-back returns the same patient, appointment, and time. The application closes its task, and the shared patient view incorporates the confirmed result.
The completed work is a confirmed booking. Attendance, patient benefit, and clinical outcomes would enter the history as separate observations.
{% endtab %}
{% tab title="Evidence" %}
### Follow the Source References
Every record in this case refers to `example-patient-001`. The evidence file retains source text, example record identifiers, observation time, receipt time, and the time each observation becomes available in the shared view.
| Source | Example record | What it establishes |
| ----------------------- | -------------------------- | ----------------------------------------------------------------------- |
| EHR prescription | `example-rx-001` | A prescription was recorded for Alex |
| Patient conversation | `example-conversation-001` | Alex reported missed doses and dizziness, and requested afternoon calls |
| Authorized measurements | `example-readings-001` | Two observations with measurement times and units |
| Clinician-reviewed note | `example-note-001` | The reviewed instruction authorizes a care-team check-in |
| Follow-up application | `example-task-001` | The selected slot and attempted scheduling action |
| Scheduling confirmation | `example-appointment-001` | The source confirmed the booking and a read-back matched it |
### Receipt, Projection, and Source Confirmation
The order shown belongs to this example. A different integration can observe these signals in a different order.
At the follow-up step, the request event has been received, its shared-view projection is still pending, and the scheduling system has not confirmed the action.
| Signal | In this illustrative case | Meaning |
| ------------------------------- | ------------------------- | -------------------------------------------------------------------------- |
| Request event received | April 10, 14:01:01 UTC | The request is recorded; the application still awaits confirmation |
| Request visible in shared view | April 10, 14:03:00 UTC | A reader can see the request; the booking is still a separate transaction |
| Booking confirmed by source | April 10, 14:04:00 UTC | The scheduling result, supported by read-back, allows the task to complete |
| Confirmed result in shared view | April 10, 14:05:00 UTC | A later application can read the confirmed outcome |
If the source response is missing or ambiguous, the task stays unresolved while its owner reconciles the scheduling record. An event receipt, approved note, or agent statement cannot substitute for source confirmation.
The [World Model](/data/world-model.md#four-invariants) explains provenance and projection. [Verify an Integration Action](https://docs.concurrence.com/developer-guide/guides/verify-an-integration-action) explains how to collect external-action evidence in a provisioned test.
{% endtab %}
{% tab title="Ownership and reuse" %}
### What Each Part Owns
| Part | Responsibility in this case |
| ---------------------------------- | -------------------------------------------------------------------------------------------------- |
| Data platform | Retain source evidence, connect the patient references, and produce the shared patient view |
| Events | Communicate accepted changes to consumers; receipt and consumer completion remain separate signals |
| Scribe | Own the note draft and clinician review |
| Configured publication integration | Publish the reviewed observation and instruction with the required patient and source references |
| Follow-up application | Own the task, channel checks, action permissions, scheduling request, and recovery |
| Scheduling system | Confirm the authoritative appointment state |
### What the Second Workflow Reuses
The follow-up application reuses the patient reference, connected prescription and measurement history, reviewed instruction, and contact preference. It does not need to ask Alex to reconstruct that history in a new conversation.
The application still needs permission to perform its specific action, a current availability lookup, and its own task and recovery state. Shared read access does not grant scheduling write access. Source access and patient visibility remain scoped to the authorized workspace and workflow.
For an evaluation, record which connectors, identity mappings, data definitions, and functions were reused; which action or channel configuration was newly required; and the effort to reach the second accepted outcome. Compare equivalent work and keep access lead time separate from implementation effort. Use the [Technical Evaluation Packet](/platform-overview/evaluation-packet.md#compare-effort-cost-and-latency) to record the result.
{% endtab %}
{% endtabs %}
## Download the Case
{% file src="/files/0w3qXfM3P0slChUuogW9" %}
Illustrative patient history, six walkthrough stages, source evidence, timestamps, and workflow responsibilities. Scenario `note-to-follow-up`, version 1.
{% endfile %}
## Continue Your Review
* [World Model](/data/world-model.md) - identity, retained observations, and serving views.
* [Shared Context and Applications](/platform-overview/shared-context-and-applications.md) - the three-part ownership map.
* [Connect Another Workflow](/data/connect-another-workflow.md) - participation contract, recovery tests, and a reuse worksheet.
* [How It Works](/platform-overview/how-it-works.md) - workflow execution and external confirmation.
* [Technical Evaluation Packet](/platform-overview/evaluation-packet.md) - acceptance criteria and a decision record.
* [Scribe: Capture to Note](https://docs.concurrence.com/developer-guide/guides/scribe-capture-to-note) - the note workflow's implementation contract.
---
# 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/data/patient-context-walkthrough.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.
