Patient Services on Life Sciences Cloud: Moving Off Health Cloud Behind the System Layer Objective: Move patient support programs from Health Cloud to Life Sciences Cloud without stopping enrollments. Put a patient-services System API in front of Health Cloud first, so hubs, pharmacies, and portals call the API rather than the org; then rebuild each step on LSC and repoint step by step. What's Getting Built Patient services (System API) — one contract over Health Cloud and LSC for patients, enrollments, and cases · POST /enrollments, GET /patients/{id}/cases Enrollment intake (Process API) — reads faxed and uploaded forms with Intelligent Document Processing and creates the enrollment · POST /intake/documents, POST /enrollments Benefits verification (Process API, or from MuleSoft Direct) — the prebuilt PSP Benefits Verification integration checks patient, insurance, prescribed drug, and preferred pharmacy against benefits vendors, payers, and the PBM to decide eligibility for financial assistance; or build it over X12 270/271 through a clearinghouse · POST /ebv, GET /ebv/{id} Missing information (Process API) — opens and chases missing-information tasks with the prescriber's office · POST /missing-info, PATCH /missing-info/{id} Financial assistance and therapy coordination (Process API) — copay and foundation assistance, then handoff to specialty pharmacy and status back · POST /assistance, POST /therapy/referral Value chain phase Phase 06 — Commercial & Patient Services. Marketing to healthcare providers (HCPs) and patient support program delivery. Scope of this plan: Patient support programs moving from Health Cloud to Life Sciences Cloud. Data in this phase: CRM (Veeva / Salesforce Life Sciences Cloud), prescription data, and logs. Receives from: Phase 05 — Supply Chain & Logistics. Hands off to: Nothing downstream — this phase closes the loop back to Research & Discovery with real-world evidence. Prerequisites Anypoint Platform org with API Manager, Runtime Manager, and a non-production deployment target. Salesforce Life Sciences Cloud org with a connected app and an integration user scoped to the objects this plan writes. Secrets Manager or secure properties configured for every system credential. Named owner for each source system — integration stalls on access, not on code. Health Cloud org access for the programs being moved. MuleSoft Intelligent Document Processing for enrollment forms. MuleSoft Direct for Life Sciences Cloud to deploy PSP Benefits Verification, or a clearinghouse for X12 270/271 eligibility, with payer coverage confirmed either way. Consent API in place, and the safety intake endpoint and reporting clock. Choose your path PSP Benefits Verification — Choose when the program's benefits vendors and PBM are covered — deploy the MuleSoft Direct integration on LSC and skip building eBV. Clearinghouse eBV — Choose when a program needs a payer the prebuilt integration doesn't reach — build the 270/271 Process API in this plan. Architecture 1. Retire Health Cloud behind the System layer Point every hub, pharmacy, and portal at the patient-services System API before rebuilding anything. Repoint one program step at a time; leave in-flight enrollments where they started until they close. 2. Enrollment and benefits Extract enrollment forms with IDP, send low-confidence fields to human review, and create the enrollment in LSC. Run benefits verification, through PSP Benefits Verification or X12 270/271, and store the coverage result on the enrollment. 3. Missing information and assistance Open a missing-information task per gap and track it to the prescriber's office with due dates. Screen for copay or foundation assistance once coverage is known. 4. Therapy coordination Refer to specialty pharmacy and bring dispense and status back to LSC for the case team. Check consent before every outreach and route any adverse event to safety inside the window. 5. Security, privacy, and GxP compliance Validate the integration under GAMP 5 — requirements, design, IQ/OQ/PQ evidence, and a traceability matrix retained for inspection. Meet 21 CFR Part 11 and EU Annex 11 for electronic records and signatures on every GxP-relevant flow. Preserve ALCOA+ data integrity — attributable, legible, contemporaneous, original, and accurate — with audit trails no operator can edit. Encrypt regulated data in transit and at rest, and keep production payload visibility to validated support roles only. Treat a mapping change on a GxP flow as a controlled change under change management, never as a hotfix. Meet HIPAA for patient data, and check consent before every patient contact. For pre-built API specifications, implementation templates, and reference architecture, see the MuleSoft Accelerator for Life Sciences on Anypoint Exchange. Testing and validation Repoint enrollment for one program and confirm new enrollments land in LSC while in-flight ones stay in Health Cloud. Send a 270 for a test patient and confirm the 271 coverage maps onto the enrollment. Report an AE in a case note and confirm safety receives it inside the window. Phased rollout Phase 1 — Connect Build the patient-services System API over Health Cloud and move callers onto it. Stand up IDP, and deploy PSP Benefits Verification or build eBV. Phase 2 — Map and validate Rebuild enrollment and eBV on LSC for one program. Add missing information, assistance, and therapy coordination. Phase 3 — Production Repoint programs one at a time. Retire the Health Cloud implementation once in-flight cases close. Success metrics Days from enrollment to first dispense. Enrollments needing manual data entry after IDP. Programs still on Health Cloud, falling to zero. Troubleshooting Enrollments split across both orgs — Likely cause: a caller still writes to Health Cloud directly. Fix: Find it in API analytics and move it to the System API. Deliverable: Patient support programs running on Life Sciences Cloud — IDP enrollment, X12 eBV, missing information, financial assistance, and therapy coordination — with Health Cloud retired behind a System API.