Patient Hub

Patient hubs coordinate services such as access support, benefits verification and case assistance. Their staff may need collection dates or delivery plans, while your operations team needs to know which support questions remain open. A configured exchange puts the relevant update beside the therapy’s operational records.

For example, a hub requests a missing document for case DEMO-001. Match the provider’s case reference to the Seal case, create a follow-up for the assigned coordinator and retain the request’s due date. Once the response is reviewed, return the approved information and track whether the hub accepted it. The example uses a synthetic case and describes a workflow to configure.

A hub connection supports patient orchestration. It does not replace the clinic’s ordering workspace, establish hospital login or grant access to a treatment-site network. Those have their own scope and operating arrangements.

Choose the updates that help your programme act. Preserve the provider’s reference, the time of the source update and the meaning of its status. The following are example exchanges; availability depends on your provider and agreed access.

Benefits-verification progress

Coverage-review status, outstanding questions and relevant effective dates. Show when the information was last refreshed so a coordinator can distinguish a current answer from an old update.

Prior-authorisation status

Submitted, pending, information required or decided status, with the provider’s references and dates. Preserve the distinction between a support-process status and the authorised team’s decision about clinical eligibility.

Information and document requests

The requested information, case reference, due date and response destination. Map the request to an owner, track its response and close it only against the agreed acknowledgement.

Case assignment and changes

Hub case identifiers, relevant programme identifiers and changes that affect coordination. Define how reassigned, duplicate, withdrawn or closed cases are handled before processing them automatically.

Share the selected milestones your support team needs. Agree which recorded states may be sent, whether review is required and how later corrections will be communicated.

Collection planning

Requested, reserved or confirmed dates, explicitly distinguished from one another. Include the relevant time zone and the reason for an approved change when your data agreement permits it.

Manufacturing milestones

Agreed progress states, revised expected dates and coordination-relevant exceptions. Send the milestone summary needed by the hub, with access to underlying manufacturing detail governed separately.

Release and delivery planning

Recorded release status, planned dispatch, expected delivery and acknowledged schedule changes. A forecast should remain distinguishable from a confirmed event or an authorised release decision.

Responses to support requests

Approved answers or document references linked to the originating request. Establish permitted attachments, delivery confirmation and handling of any rejected response.

Start with a data contract that both teams can review. Identify the source of record for each field, the permitted values, how cases are matched and which transitions the exchange may initiate. Keep an inbound support update separate from any decision that requires a clinician, coordinator or quality reviewer.

Use the programme and provider case references together when needed to make the match unambiguous. An unknown or conflicting reference should go to a review path. Define how a corrected mapping is approved and how affected updates are replayed without producing duplicate records or tasks.

Identifiers and scope

Programme, provider case, Seal case and event or message reference. Agree the uniqueness rules and the process for linking an existing case.

Status and field mapping

Document each source status and its destination meaning. Preserve the original value where useful for investigation, and route new or unsupported values for review.

Dates and sequence

Distinguish when an event occurred from when it was received. Define time zones, effective dates and what happens if a correction or older event arrives later.

Minimum information

Select the patient attributes and document content required for the exchange. Case references do not by themselves determine the sensitivity of the information; review the complete payload and access model.

Use a Seal script for the agreed provider calls, mapping and record updates. Configure the trigger around the workflow: a scheduled retrieval, an authorised case action or a supported event-driven exchange. Keep the provider credentials in the configured secret store and scope the script’s access to the records it needs.

Record enough exchange information to trace the outcome: the message reference, case match, source time, processing result, destination response and any follow-up. Seal’s script execution logs help investigate a run; the programme-specific exchange record and operational queue are configured as part of the connection.

For outbound updates, distinguish a successful network request from the provider accepting and applying the information. Some interfaces acknowledge receipt first and return processing results later. Define which response constitutes completion and which failures need action.

A useful integration has an agreed response when the expected exchange does not happen. Define these behaviours with the provider and demonstrate them during acceptance.

Duplicate messages

Use the provider’s event reference or another agreed duplicate-detection rule to prevent repeat events from creating repeated tasks or overwriting a later state.

Out-of-order updates

Compare source sequence or effective time where supported. Decide when an older message is historical evidence, a correction or an exception requiring review.

Unknown cases or fields

Hold the update for review with a clear reason and owner. Correct the mapping or source information before applying it, then preserve the resolution.

Timeouts and provider outages

Agree retry limits, backoff and escalation. Avoid assuming a timed-out write failed: check the provider’s result or use its duplicate-safe submission mechanism before sending again.

Rejected responses and stale data

Surface the provider’s rejection reason and the last successful exchange. Establish reconciliation so a silent gap can be found even when no explicit error arrives.

Scope delivery against the actual hub contract and interface. A general statement that a provider has an API is a starting point; the programme also needs permission to use the relevant operations and data.

Interface and test access

API or file specification, representative sample messages, authentication requirements, network restrictions and test-environment access. Confirm any provider onboarding or connection charges.

Workflow and volume

The first use case, fields and directions, expected frequency, peak volume and acceptable delay. Identify which updates are operationally time-sensitive.

Named technical owners

Contacts on both sides for configuration, access, schema changes and incidents. Agree who investigates each class of failure and how issues are escalated.

Operating agreement

Source ownership, permitted use, support hours, retention, recovery, change notification and the checks required before a revised interface is released.

Begin with a synthetic case and follow a complete request-and-response cycle. Receive the hub update, match the case, create the expected action, review the response, send it and verify the provider’s acknowledgement. Reconcile the result on both sides.

Then exercise the failures that matter: duplicate events, incorrect references, unsupported statuses, missing required fields, expired credentials, rejected submissions and interrupted transfers. Check that retries preserve the intended result, reviewers can resolve exceptions and unauthorised users cannot see or send the information.

Keep the agreed requirements, mapping, configuration version, test results and release decision together. The acceptance criteria should describe the programme’s actual exchange and the responsibilities of both parties.

Agree who checks outstanding exchanges, stale cases, failures and reconciliation results. A support owner should be able to identify what arrived, what was applied, what was acknowledged and what still needs attention. Define a manual coordination process for an extended outage and reconcile any updates made during it.

Treat a provider schema change, credential rotation or new programme mapping as an operational change. Test the affected flow before release, preserve the previous mapping and agree recovery steps. When a programme ends or changes provider, define the final reconciliation, permitted data export, retention and access removal.