The platform needed to serve three distinct audiences—patients, family caregivers, and licensed healthcare professionals (HCPs)—from a single codebase, with content that is strictly gated by role. Any leakage of prescriber-only dosing or off-label information into the patient-facing experience would create regulatory exposure, so the access model had to be enforced at the API layer, not just hidden in the UI.
WCAG 2.1 AA accessibility compliance was a hard requirement, not a nice-to-have, because the rare-disease patient population includes many users with limited mobility, low vision, or cognitive fatigue from treatment. Existing internal prototypes had been built without accessibility in mind and would have required a near-total rebuild of the component library to retrofit.
Every piece of patient-facing medical content had to pass through a multi-stage regulatory approval workflow involving medical, legal, and regulatory (MLR) reviewers before publication. The client's prior process ran this review over email and shared spreadsheets, routinely taking two to three weeks per content update and creating no reliable audit trail of who approved what version.
Sensitive medical and personally identifiable data had to be handled under HIPAA-aligned controls, including encryption, field-level access restrictions, and detailed audit logging, even though the platform itself was not technically a covered entity. The client's compliance team required documented evidence of controls for their own audit purposes, not just a verbal assurance of best practice.
Family caregivers needed a genuine peer-support community, but unmoderated forums in a rare-disease context carry real risk: users sharing unverified treatment advice, emotional crisis disclosures, or inadvertent protected health information in public posts. The client needed automated flagging plus a trained human escalation path, not just a report button that goes nowhere.
The organization operated across multiple countries with different regulatory bodies (FDA in the US, plus emerging requirements in other markets), meaning content localization and region-specific approval gates had to be built into the same pipeline rather than bolted on later as separate systems.
Internal IT had no existing DevOps practice for this kind of regulated SaaS product, so the platform needed infrastructure that could demonstrate uptime, disaster recovery, and change-control evidence to auditors on demand, without requiring the client to hire a dedicated platform engineering team.
The seven-month timeline was fixed to align with a planned treatment announcement, leaving no room for the accessibility audit, security review, or MLR sign-off to slip without jeopardizing the launch date entirely.