> 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/connect-another-workflow.md).
# Connect Another Workflow
Plan a second healthcare workflow around reusable context, explicit application ownership, failure recovery, and measured integration effort.
The useful test of a shared data foundation is a second valuable workflow that works coherently with the first. Reuse the source connections, patient identity, evidence, and functions that fit the new task. Define the new application's actions and responsibilities separately.
This is a planning and acceptance guide, not a runnable integration recipe. Before implementation, identify an authorized workspace, confirmed source and interface access, an owner for each workflow, and a target system or test environment for actions. Use the relevant [Developer Guide](https://docs.concurrence.com/developer-guide) contract for API details.
## Start with the Second Outcome
Choose a specific next job, its operating owner, and its evidence of completion. In the [patient walkthrough](/data/patient-context-walkthrough.md), the first workflow produces a clinician-reviewed note and check-in instruction. The second produces a confirmed booking. It reuses context without treating the note as booking permission or the booking as completed care.
Reuse the foundation. Keep the new workflow's authority, task state, and recovery explicit.
## Agree on the Application Contract
Complete these questions for each boundary before connecting the applications. They are review requirements, not fields in a new API schema.
| Boundary | Record in the integration plan |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Read** | Required entities and fields, permitted sources, acceptable age, and behavior when information is missing or conflicting |
| **Publish** | Source and entity references, what happened, effective and observation times, receipt evidence, and how corrections refer to earlier evidence |
| **React** | Trigger meaning, subscription owner, supported delivery and ordering behavior, deduplication, retry, replay, and reconciliation |
| **Own** | Authoritative task state, transaction boundary, approval policy, and which service prevents conflicting actions |
| **Write back** | Authorized target and action, proposal or approval requirements, confirmation evidence, and handling of uncertain results |
| **Operate** | Schema and mapping owners, support handoff, audit access, stop conditions, and recovery owner |
Event receipt, updated shared context, and action completion are separate checkpoints. Keep durable application work records and verify the selected publication path's recovery behavior. Do not assume that an application save and an event publication are atomic, or that every consumer supports replay. See [Shared Context and Applications](/platform-overview/shared-context-and-applications.md).
Access must be evaluated again for the new purpose. Reusing ingestion does not automatically authorize a new recipient, channel, or external mutation. Define what happens to queued and active tasks if access or consent changes.
## Separate Reuse from New Work
| Reuse candidate | Validate again | Often specific to the new workflow |
| ------------------------ | ------------------------------------------------------------------- | -------------------------------------------------------- |
| Source connection | Scope, source coverage, freshness, and operational owner | Additional source permissions or records |
| Entity mapping | Correct patient and related records, including ambiguous identities | New identifiers or relationship types |
| Shared facts and views | Provenance, units, time meaning, missingness, and corrections | A task-specific view or cohort definition |
| Function or tool | Input contract, permitted use, behavior, and test coverage | New domain logic or action authority |
| Operational capabilities | Evidence access, support coverage, and failure handling | Task state, approval rules, channels, and reconciliation |
Existing code is not necessarily a reusable product contract. Confirm supported inputs, ownership, and change management before depending on a function. A function definition alone does not establish a clinically validated library.
## Exercise the Failure Path
Use synthetic records first. Observe both applications and the authoritative target, not just the event stream.
| Test | Acceptance evidence |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| A source correction changes relevant context | The new view is inspected and affected pending tasks are rechecked under an explicit application policy |
| Required context is late or unavailable | The consumer waits, retrieves authoritative data, or escalates rather than silently proceeding with an unsuitable view |
| A trigger is repeated or arrives out of order | The application reconciles with its task state and does not perform an unintended duplicate action |
| Two applications request conflicting mutations | The authoritative service rejects or serializes the conflict; a broadcast is not the enforcement mechanism |
| Approval is denied or access is revoked | No prohibited action proceeds; queued work is handled under the agreed policy |
| A response is lost after submission | The task remains unresolved until target evidence is reconciled; no blind retry of a non-idempotent mutation |
A correction does not undo an external action already completed. Define whether it requires cancellation, compensating work, or human review. Keep the original outcome and the corrective action distinguishable in the evidence.
Before testing, agree how to end sessions, cancel synthetic tasks or bookings where appropriate, and dispose of test data under the environment's retention rules. Production adds actual access agreements, channel provisioning, operating coverage, volume, and monitoring; passing a synthetic case does not establish those conditions.
## Measure the Second Accepted Outcome
Use the same outcome definition and a recorded baseline. Separate calendar waiting for access from active mapping, implementation, validation, and support effort. Report both successful and unresolved cases; a faster happy path alone does not establish lower total effort.
{% file src="/files/x9Uize4D791exYJJuD1B" %}
First-to-second workflow comparison: reused foundations, new work, owners, acceptance evidence, and operating effort. Blank planning worksheet, not measured results.
{% endfile %}
Record time to first and second accepted value, implementation and support hours, reused components, unresolved identity conflicts, stale-context incidents, failed or duplicate actions, and workflow-owner acceptance. Attach the evidence and denominators for any claimed improvement. Do not fill missing measurements with estimates presented as results.
Finish with a decision: proceed within scope, resolve named conditions, or hold. Ask another implementation owner to repeat the setup from the recorded package; that tests whether reuse depends on the original team's undocumented knowledge. Add the decision and operating handoff to the [Technical Evaluation Packet](/platform-overview/evaluation-packet.md#evaluate-first-to-second-workflow-reuse).
---
# 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/connect-another-workflow.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.
