Portals and workflow applications for investigators, sites, CROs, suppliers, partners and patients, built around external identity, approval records that stand as evidence, and workflows that survive being changed.
Every other application in your estate serves employees. Somebody joins, somebody leaves, and a human resources process tells the systems. A portal serves people who work for organizations you do not control, and nobody tells you anything.
Internal identity management works because the organization owns the employment relationship. Joining, moving and leaving all generate an event, and the systems respond to it.
External identity has none of that. Access is granted at the start of a relationship by somebody with a deadline, and there is no corresponding event at the end.
External accounts are never deprovisioned
Because no event tells you the relationship ended.
The portal became a second place to do work
So the first place is still email and now there are two.
Approvals route correctly and record nothing useful
Who approved is captured, what they approved is not.
A workflow changed while instances were in flight
And nobody can say which version each one is running.
Low-code flows multiplied without an owner
Several hundred, a handful critical, nobody sure which.
Legacy portals cannot be changed or retired
Because the integrations into them are undocumented.
Access control differs between portals
So the same partner sees different things for no reason.
Status has to be chased rather than seen
Which is the original reason somebody asked for a portal.
Export the external user list from one portal and review it line by line.
Take a single portal, export every external account, and establish for each one whether that person still holds the relationship the access was granted for, and who in your organization currently owns that decision. In most organizations this has never been done, a material proportion of the accounts are stale, and nobody can name the owner for a significant number of them. It requires no technology, takes a day, and it is the most useful security and data integrity finding available on this page.
The documented process and the actual process differ, and the difference is where the portal either succeeds or becomes shelfware. The sequence below starts with the actual one.
Step 1
Assess the process as executed, including every handoff outside the system
Step 2
Discover who the external users actually are, and how they arrive and leave
Step 3
Map the workflow with decision points, waits and exceptions separated
Step 4
Design the external experience for the occasional user, not the daily one
Step 5
Architect identity first: provisioning, scoping, expiry and review
Step 6
Develop workflows as versioned, configurable definitions
Step 7
Integrate to the systems of record rather than copying them
Step 8
Automate the deterministic steps and leave the judgement visible
Step 9
Test the exception paths, which is where portals actually fail
Step 10
Validate where the workflow touches controlled records
Step 11
Deploy by replacing the old path rather than running beside it
Step 12
Govern identity, workflow definitions and low-code assets with named owners
Step 13
Monitor completion time, backlog, adoption and stale access together
Take one completed approval and try to prove what was approved.
Pick a closed approval from a few months ago and establish, from the system alone, exactly which version of the document or record the approver saw, what else was visible to them at that moment, and when they decided as opposed to when the record was updated. If the system holds a link to a document that has since been revised, the approval is attached to a moving target and proves nothing. That check takes twenty minutes and it tells you whether your workflow estate produces records or receipts.
Grouped by audience, because the audience determines almost everything: identity model, friction tolerance, device, and what the record has to prove.
Clinical and research audiences
Investigator and clinical site portals for onboarding, document exchange, training records and study communication
Sponsor and CRO collaboration portals, where the estate spans two organizations and the handover is designed at the start
Patient and participant portals for self-service, scheduling, information access and study communication
Research collaboration platforms with contributed data distinguishable by origin and intellectual property controls designed in
Regulatory, quality and supply audiences
Regulatory submission and document portals with version-level control and defensible approval records
Quality management workflows: quality events, corrective and preventive action tracking, change control
Supplier and partner portals including qualification, documentation and periodic review
Contract approval workflows with state, evidence and timing captured
Commercial and cross-functional
HCP engagement and information access portals, with the promotional controls our Commercial Applications page describes
Commercial operations portals for internal cross-functional coordination
Approval workflow automation across functions, with deterministic steps automated and judgement left visible
AI-powered workflow assistants that summarise, route and prepare, and do not decide
Legacy portal modernisation, including the ones that cannot currently be retired because the integrations are undocumented
The third column is the point of the table. Most of these look like document or task problems and resolve to the same question: who is this person, what are they entitled to see, and when does that stop.
| Use case | What it delivers | The identity question underneath |
|---|---|---|
| Clinical site onboarding | Activation steps tracked to completion | Access before the agreement is signed, scoped how |
| Investigator collaboration | A single place for study communication | The investigator who moves institution mid-study |
| Study document exchange | Controlled exchange with version integrity | Who at the site may see which document |
| Research project coordination | Shared workspace across organizations | Contributed data attributable by origin |
| Patient self-service | Scheduling, information and communication | Verification without creating a barrier |
| Regulatory document review | Review and approval with evidence | Approver identified individually, not by group |
| Quality event management | Events raised, triaged and closed | External reporters, often from suppliers |
| CAPA workflow tracking | Actions tracked to effectiveness check | Ownership surviving a personnel change |
| Change control | Change assessed, approved and recorded | Approver authority evidenced at the time |
| Supplier qualification | Qualification status and documentation current | Expiring documents and expiring contacts |
| Contract approvals | Terms routed, approved and recorded | Delegated authority, and its limits |
| HCP information access | Authorised information on request | Consent and promotional scope at access time |
The most common architectural mistake in portal work is for the portal to become a data store. It accumulates copies of documents, statuses and records that exist authoritatively elsewhere, and from that point the organization has two versions of everything.
An identity layer handling external users: provisioning, verification, scoping to study, site, contract or account, expiry by default and periodic review
A presentation layer designed for the occasional external user, on whatever device they have, with the task completable in one visit
A workflow engine holding versioned definitions, with every instance stamped with the version it started under
An integration layer reading from and writing to the systems of record rather than copying them, so the portal surfaces rather than stores
A document layer where the portal references controlled documents at a version rather than holding its own copies
An audit layer recording access, actions, approvals and exchanges, which is frequently the only complete record of an external interaction
Portal and workflow platforms: Microsoft Power Pages, Power Apps, Power Automate, SharePoint, Dynamics 365, Salesforce, ServiceNow, and workflow orchestration engines
Clinical and research systems: CTMS, eTMF, LIMS, ELN, and EHR connectivity where appropriately authorised
Quality and enterprise systems: QMS and ERP
Identity and access management as a first-class component rather than a configuration step
Cloud and integration: Microsoft Azure, AWS, API-based integration services
Analytics and intelligence: Microsoft Fabric, Power BI, AI and machine learning frameworks
Count how many copies of one document exist across your portals.
Take a document that several audiences need, a protocol, a specification or a qualification certificate, and find every place it currently sits: each portal, each shared folder, each attachment in a workflow. Then check whether they are the same version. In most estates they are not, and the portal that holds a copy rather than a reference is the mechanism by which an obsolete version stays in circulation. That count takes an afternoon and it usually settles the architecture argument.
Regulatory applicability, system classification and validation strategy are determined by your qualified quality, regulatory and legal functions. We do not interpret those frameworks and this page does not state which apply to you.
Technology supports a compliance programme. It does not independently establish compliance, and no portal makes an organization compliant.
External identity
- Provisioning with verification proportionate to what the access permits, and a named internal sponsor for every external account
- Access scoped to the study, site, contract or account it was granted for, and scoped differently per partner type, since a CRO, a contract manufacturer, a laboratory, a supplier, a distributor and a technology partner each sit under a different agreement and need a different view
- Expiry by default, with extension requiring a positive act, because removal on request depends on an event that never arrives
- Periodic review by the internal sponsor, with unreviewed access suspended rather than carried forward
- Multi-factor authentication, and federation where the external organization can support it
Records and integrity
- Electronic signature capability built to the requirements your quality function specifies
- Audit trails over access, actions, approvals, document exchange and workflow changes, that a user cannot alter or disable
- Document version control, with the portal referencing a controlled version rather than holding an uncontrolled copy
- Workflow definition versions retained, with every instance attributable to the version it ran under
Validation and change
- Systems engineered to be validatable: requirements traceable, configuration versioned, evidence as a build output
- Validation scope and approach determined by your quality function, with our role being to supply what it asks for
- A rule agreed in advance about which low-code asset categories may touch a controlled record, and what that obliges
- A register of portal and workflow assets with criticality classification and a named owner per asset
Privacy, security and AI
- GDPR and other applicable privacy requirements as your privacy function determines, including lawful basis for any participant-facing portal
- Secure data exchange and retention policies applied per data class and per external relationship
- An end-of-relationship position settled before build: what is retained, what is archived, what is deleted, who may still retrieve it afterwards, and what the external party is entitled to keep
- Defined intended use for any AI capability, with deciding or approving explicitly outside it. Specifically, no AI output approves a regulated document, closes a quality event, completes a change control, or makes any other decision reserved for authorised personnel
- Human review recorded as a workflow step where an AI output informs a controlled decision
A portal that is available, fast and quietly bypassed will be reported as healthy. The measures that matter are about where work sits and how long it sits there.
| Failure | How it presents |
|---|---|
| Stale external access accumulating | Accounts live for relationships that ended |
| The process reverted to email | The portal is available, and the work is going round it |
| A workflow stalls on one step | Backlog ages at a single approver with no escalation |
| A workflow version changed mid-flight | Instances completed under a process nobody can reconstruct |
| An approval has no version reference | The record proves a click and not a decision |
| Low-code assets multiplying unowned | Nobody can say which flows are operationally critical |
| Documents copied rather than referenced | An obsolete version is in circulation through a portal |
| Automation overridden routinely | The automation does not match the work and costs time |
| Onboarding slower than the deadline | Access is pending and the work happened another way |
| Reassignment rate high on one step | The routing is wrong and people are correcting it by hand |
| Closed relationships still holding live records | The operational portal has become an undesigned archive |
The outcomes below follow from two choices: external identity handled as the primary requirement, and the portal removing a step rather than adding one.
Manual coordination reduced, measured in chasing eliminated rather than in screens delivered
Approvals accelerated, with turnaround reported by step so the actual constraint is visible
Stakeholder collaboration strengthened because the external user has one place and it is faster than their inbox
Process visibility improved, with status derived from the work rather than reported by a person
Regulatory readiness supported by approval records that identify what was approved, at which version, by whom
Disconnected workflows eliminated rather than supplemented, which requires retiring the old path deliberately
Legacy portals modernised and, where appropriate, retired, with their undocumented integrations mapped first
An access position you can actually state: who has access to what, scoped how, expiring when
Expect the external account review to find stale access and unowned accounts.
Expect at least one portal-enabled process to still be running on email. Expect approval records that cannot show what was approved. Expect the low-code inventory to be larger than anybody estimates. And expect the hardest part to be retiring the old path, because somebody will always have a reason to keep it available for exceptions.
We will take one portal and one workflow and establish what your estate can evidence: the external access position, the approval record quality, and whether the process actually moved off email. You get the findings whether or not we build anything.
CaliberFocus builds secure portals and workflow applications for investigators, sites, CROs, suppliers, partners and patients. We treat external identity as the primary requirement, scope and expire access by default, version every workflow definition, capture approvals with enough context to stand as evidence, and design portals that reference records rather than copying them.
- External access scoped narrowly and expiring by default
- Approval records that show exactly what was approved, at which version
- Versioned workflows with in-flight instances tracked to their version
- Low-code governed with a register, owners and criticality
Security & Compliance
