Comprehensive Study Management¶

From a user perspective, the “single source of truth and login” vision is compelling, and it is achievable without turning Metricis into an unmanageable monolith if you are disciplined about (1) what must be first-class vs integrated, (2) information architecture, and (3) modular boundaries.

1. Start with the user journey, not the feature list¶

A unified platform should map to the daily “jobs to be done” for each persona. In trials, most tasks cluster into a small number of workflows:

If Metricis becomes the place where each persona can complete their workflow without context-switching, it will feel like “one system,” even if some functions are integrated rather than built.

2. Define the “platform kernel” that must remain simple¶

To avoid overwhelm, Metricis should have a small, stable core (kernel) that everything else hangs off:

Identity, SSO, RBAC (site vs sponsor vs monitor vs PI vs coordinator)
Study + site + participant entities
Event/visit timeline (even if some studies are non-visit-based)
Audit log, immutable activity stream
Notifications/tasks
A consistent “study home” and navigation model

This kernel is what creates the “one login / one source of truth” experience.

3. Treat new functions as modules with strict boundaries¶

Instead of “adding features,” think “adding modules,” each with:

Clear scope
A minimal set of shared objects (study, site, user, participant, visit)
A well-defined event model (what actions are logged)
A clear exit path (export/hand-off) so it never becomes a trap

Candidate modules you mentioned¶

A. Training presentation + logging¶

User value is high because it reduces compliance friction.

Minimum viable scope:

Training catalog (role-based assignments per study/site)
Delivery: link, embedded video/PDF, or SCORM/xAPI integration
Completion: attestation, quiz (optional), timestamped log, renewal schedule
Evidence: downloadable training report and per-user transcript

Avoid scope creep:

Do not build a full LMS if integration (SCORM/xAPI) can cover it.
Keep “content authoring” minimal; focus on assignment and audit-grade logs.

B. eRegulatory document management¶

This is where platforms get heavy quickly; a pragmatic model is best.

Minimum viable scope:

Document library per study/site with standard folders (essential docs)
Versioning + signatures/attestations (as applicable)
Expiry tracking (licenses, CVs, GCP certs, delegation logs)
Inspection mode: “show me what’s current and complete”

Critical decision:

Whether Metricis stores documents or brokers to a validated eTMF/EDMS (often preferable). User-centric compromise:
Single UI for discovery and status, with storage possibly external.

C. Study dashboard reporting¶

This is a “must” if Metricis becomes a hub.

Minimum viable scope:

Enrollment and screen-fail funnel
Visit adherence and window compliance
Missing data and overdue ePROs
Query burden and turnaround time
Data entry timeliness by site
Basic risk indicators (central monitoring-lite)

Avoid scope creep:

Do not try to replicate a full BI platform; focus on operational trial health.

4. Information architecture that prevents overwhelm¶

A pattern that works well is a fixed top nav with 5–7 items maximum, plus context-sensitive subnavigation:

Study Home (timeline + key alerts)
Participants (list + visit schedule)
Data (ePRO/EDC instruments, queries)
Documents (eReg + training evidence)
Oversight (dashboards + monitoring)
Admin (roles, sites, configuration)

Within each module, use the same layout: left nav, main content, right “activity panel” showing the audit stream for the current object (participant, visit, document).

5. “One source of truth” without forcing everything into one database¶

From a user standpoint, “one source of truth” means:

One identity
One canonical study configuration
One authoritative status for what’s done / pending
One audit trail of activity

Technically, you can deliver that with a hub-and-spoke model:

Metricis is the orchestration hub and status layer
Specialized systems remain systems-of-record where appropriate (eTMF, eConsent, safety)
Metricis holds pointers, statuses, evidence hashes, and activity logs

This lowers validation burden and avoids re-building mature categories.

6. What to make first-class vs integrate¶

A practical heuristic:

Make it first-class in Metricis if:

It is performed daily/weekly by coordinators/participants
It directly impacts timeliness/completeness of participant data
Integration options are poor or overly expensive

Integrate (do not rebuild) if:

The category is heavily regulated/validated (full eTMF, safety DB)
Mature solutions exist and stakeholders already use them
The module would create long-term maintenance and compliance debt

In your list, training logs and operational dashboards are typically good “first-class” additions. Full eReg document management is often best as “status + access + evidence” with optional storage.

7. A safe “Phase 1” scope that tests the concept¶

If you want to explore this idea without overwhelming the product:

Phase 1 modules:

Training assignments + completion logs (with attestations)
Study operational dashboard (timeliness, missingness, visit status)
Universal activity stream (audit-grade) across ePRO + training + docs

This creates real “one login” value quickly and gives you user feedback on navigation and cognitive load.

8. Success measures from a user perspective¶

If Metricis is working as a unified platform, users should experience:

Fewer logins and fewer “where do I find that?” moments
Shorter time to onboard a new coordinator
Clear “what do I need to do today?” queue
Faster site readiness checks (training/docs/currentness)
Faster monitoring conversations (shared dashboards)

If you want, I can translate this into a concrete product artifact:

A one-page “Metricis as Study Operations Hub” concept brief (personas, modules, IA)
A module boundary diagram (kernel + plugins + integrations)
A prioritized backlog with MVP/phase gates and explicit “won’t do” guardrails