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 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, 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.

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.

workflow-reuse-worksheet.csv

1KB

Open

First-to-second workflow comparison: reused foundations, new work, owners, acceptance evidence, and operating effort. Blank planning worksheet, not measured results.

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.