01
Scope record
Named service, users, workflow boundaries, data sources, exclusions and clinical owners.
Pilot
Start with a defined clinical setting.
SIJILL is in active development, with staged pilot deployments underway. A pilot is meant to test fit, safety and workflow value in a bounded environment before broader use.
Approach
A pilot should answer a small number of real questions.
The aim is not to reproduce an entire hospital deployment on day one. It is to choose a workflow worth testing, define who owns it, decide what success looks like and review what happens in practice.
01 · SCOPE
Choose the settingDefine the service, unit or workflow, the users involved and the clinical boundaries of the pilot.
02 · CONFIGURE
Align local structuresMap roles, documentation, reference content, protocol ownership and responsibility states to local practice.
03 · VALIDATE
Test before live useUse simulation and synthetic or governed demonstration data where appropriate to review workflow behavior, safety gates and edge cases.
04 · PILOT
Run narrowlyIntroduce SIJILL to a defined clinical group with clear ownership, support and escalation paths.
05 · REVIEW
Measure and decideReview workflow fit, safety, adoption and measurable closure before any expansion.
Pilot outputs
A pilot should leave behind evidence, not impressions.
Before work begins, the institution and SIJILL agree what will be configured, what will be measured and what evidence is required to decide whether the workflow should continue or expand.
02
Configuration record
Roles, local content, protocol versions, responsibility states and interface assumptions.
03
Validation record
Simulation cases, observed failures, safety-gate behavior, regression results and remediation.
04
Operational measures
Defined measures such as result closure, handoff completion, time-to-information and follow-up visibility.
05
User review
Structured feedback from clinicians, leadership, IT and governance stakeholders.
06
Expansion decision
A documented decision to stop, revise, continue or broaden the pilot based on agreed evidence.
ICU example
A focused high-acuity pilot.
An ICU or acute-care pilot can test patient-state visibility and supervised workflow automation without treating the unit as a full-scale rollout.
One unit. Defined protocols. Named clinical ownership. Measurable review.
01
Patient-state visibilityAcuity, support, new results, pending work and critical findings in one current view.
02
Supervised protocol workflowPrepared actions pass through a safety gate and responsible-clinician authorization.
03
Closed-loop follow-upMonitoring and reassessment remain attached to what was staged and why.
04
EvaluationPossible measures include handoff completion, pending-result closure, time-to-information and pathway adherence.
Before expansion
What gets reviewed.
The pilot should produce a concrete record of what worked, where friction remained and what would need to change before broader deployment.
01
Clinical fit
Does the workflow match how the team actually works at the bedside?
02
Safety
Are boundaries, safety gates, authorization and escalation clear?
03
Closure
Are pending results, tasks, reassessment and ownership easier to follow?
04
Governance
Are local content ownership, provenance and review states explicit?
05
Usability
Can clinicians find the relevant patient state without rebuilding it?
06
Expansion decision
Scale only where the pilot supports a clear clinical and operational case.
Discuss a defined SIJILL pilot.
Start with the workflow you want to test, the people who own it and the questions you want the pilot to answer.