Connect the patient journey to manufacturing.

1Connect the programme to the manufacturing work.

Patient orchestration connects the people and decisions that move a therapy from treatment order to collection, manufacturing and return. The clinic needs to know its next action. Manufacturing needs the right material and an agreed schedule. Programme operations needs to see where a change puts the plan at risk.

When a collection date changes, the manufacturing plan may need to change with it. When QC puts a product on hold, the coordinator needs the context to replan. That is hard when the orchestration portal is separate from the manufacturing record that changed. Seal links the clinic’s request to its patient-specific material, batch, QC and release records, and a reviewed update reaches the right action list with the affected case, the revised plan and the person responsible for follow-up.

Seal provides the manufacturing and quality workflows, linked records, access controls, scripts and APIs. Your programme implementation defines the clinic experience, scheduling rules, identity controls and partner connections, and verifies them together before operational use.

1.1Why teams choose Seal for patient orchestration

A standalone therapy portal coordinates the clinic but sees manufacturing through status messages passed across an interface, so a changed date or QC hold reaches the coordinator late and without its context. Seal runs orchestration on the platform that runs manufacturing, so a coordinator works from the underlying operational change and follows its consequences to the receiving team. The clinic workflow is configuration on that platform, and adding a treatment centre or changing a step is a versioned, approved change rather than a portal release. The cell therapy manufacturing blueprint covers the connected manufacturing operation.

2Give each clinic a clear case and next action.

A treatment request needs enough structure for the next team to act: the programme and product, treating centre, authorised patient reference, requested collection date, prerequisites and responsible coordinator. Keep a draft request separate from an accepted order, and make requests for missing information part of the case history.

Define the milestones that matter for your therapy, for example request received, collection planned, material received, manufacturing in progress, release under review and return arranged. Each transition needs an owner, required evidence and an agreed meaning, and a status should answer an operational question. “Awaiting information” names what is missing and who should respond; “collection planned” distinguishes a requested date from confirmed capacity. Cancellation, withdrawal and repeat collection are defined explicitly, because they affect capacity, material and partners differently.

Each treatment centre has its own access boundary, verified across records, search, attachments and notifications. Hospital sign-in establishes who the user is; their assigned permissions determine which programme records and actions they can reach.

3Schedule collection against real capacity.

A booking is a promise about downstream resources: the collection slot, manufacturing window, transport lane, laboratory capacity and any time-sensitive material constraints. Define reservation, confirmation, cancellation and rescheduling rules against those resources, when a requested date becomes a commitment, and which confirmations need a planner’s review.

Test the rules with the cases that break them. When two clinics request the final manufacturing slot, the result should be one confirmed reservation and a clear alternative or review path for the other. If the first clinic cancels, capacity is released through the agreed process and the cancellation is preserved. A remaining-capacity number on a screen is only useful when reservation and release behave consistently.

4Carry identity and custody through every handoff.

Chain of identity links the intended patient to their material; chain of custody records who held it, where, when and in what condition. For each critical handoff, agree the expected identifiers, container or shipment, sender, receiver, condition and acknowledgement, and how splits, samples, relabelling and repeat collections stay associated with the right case.

A barcode field is a reusable component; the programme must also establish how a failed check prevents the next action. A delivery with an unexpected identifier enters a visible exception path: the observed and expected values are recorded, the affected action is held, and the decision to correct, accept or reject is retained under the approved procedure. The next step stays unavailable until that resolution is recorded.

Release, dispatch readiness, delivery and clinical readiness are related milestones with different owners. A courier status update has a defined meaning for the programme rather than completing every downstream milestone automatically. When a delivery is delayed or a condition exception occurs, a named reviewer assesses the impact and communicates the revised plan. Clinical treatment decisions remain with the authorised clinical team.

5A changed manufacturing date, worked through.

In synthetic case DEMO-001, collection is confirmed and manufacturing has begun when a laboratory review changes the expected release date. The implementation should define this sequence and demonstrate it during acceptance.

1. Record the source change. Link the revised expectation to the relevant manufacturing or QC record, with the reason and responsible team.
2. Review the programme impact. Identify affected delivery arrangements, clinic actions and patient-support coordination, and assign a person to agree the revised plan.
3. Share the approved update. Send the permitted milestone and dates to the clinic and required partners, keeping forecast dates distinct from confirmed commitments.
4. Capture the response. Record whether the clinic acknowledged the change, requested another date or needs more information, and escalate an overdue response.
5. Reconcile the plan. Confirm that programme, manufacturing, logistics and clinic records reflect the approved outcome, preserving earlier plans and the decisions that changed them.

6Onboard clinics and partners as part of delivery.

Technical setup is only part of a site’s schedule; hospital review, access approval and programme acceptance determine when it can begin. Keep a site activation record for each treatment centre (contact, identity provider, account owners, review status, training and target date), and distinguish a clinic that can sign in from one that is ready for its first case.

Seal supports Microsoft Entra ID and Google Workspace sign-in. Confirm each clinic’s provider, coordinate any administrator consent and provision named users with programme access; assess other providers and automated provisioning during solution design. Prepare a reusable package for hospital security review: data flows, hosting and access details, security evidence, continuity arrangements and account-management responsibilities. UCSF’s published assessment process, for example, covers new systems and significant changes, with findings returned to the system owner.

Identify each hospital, courier and patient-support connection individually. A hospital login provides access to the application; exchanging information with a medical-record system needs its own agreed interface, data scope and testing. Patient-support hubs may provide benefits-verification status, prior-authorisation updates and case references, and receive selected dates and milestones at agreed points. For each provider, agree identifiers, permitted fields, direction, timing and source of record, and test duplicate, out-of-order and interrupted messages. A data connection does not confer patient-network membership. See the patient-hub integration.

7Evaluate the current platform and plan the transition.

If your clinics already use an existing therapy orchestration portal, establish what that means for the new therapy. Familiar screens, a hospital login connection, a prior supplier review and a clinical-data interface each save different work, and each needs confirming for the treatment centres you will use. Some portal providers offer a shared clinic login or dashboard that spans several therapies and third-party tools; access to one can be investigated with its operator, but compatibility, terms and access would need agreement before forming part of a delivery commitment.

Compare the complete scope: clinic workflows, scheduling, identity and custody, manufacturing coordination, interfaces, support and rollout. For an existing programme, inventory open cases, future bookings and shipment references, map identifiers and status meanings, and agree the cutover boundary. Imported history stays distinguishable from actions performed after migration. During any transition, name the writer for each field so two systems cannot confirm the same capacity, and rehearse the cutover with rollback criteria.

8Start with one clinic and a repeatable rollout.

1. Map the sites. Identify treatment centres, IT contacts, current portals, required connections and intended start dates, with the responsibilities of Seal, your programme team and each partner.
2. Define the first workflow. Agree enrolment, treatment orders, patient references, roles, scheduling rules and handoffs.
3. Prove the journey. Use synthetic cases to exercise access, booking, identity checks and manufacturing updates, including two users competing for capacity, a user from the wrong clinic, a mismatched label, a withdrawn case, a late acknowledgement and a partner transfer that times out.
4. Activate and expand. Complete the site’s review and acceptance, train its users, agree support ownership for login failures, booking exceptions and interrupted exchanges, and reuse the package for each additional clinic.

Record the configuration version, acceptance results and release decision through your intended-use controls, and configure operational measures teams can act on, such as unacknowledged date changes and unresolved identity exceptions. Bring your clinic list, current systems and intended start date to discuss your patient orchestration programme with Seal.