Judicial Itineraries (JI) - Data Dependencies

JI is largely a standalone system with limited direct integrations. Most data exchange is file-based (Excel exports) or email-based rather than API-driven. The system both consumes and produces data critical to HMCTS judicial operations.

#	Direction	External System	Data	Mechanism	Criticality
1	Inbound	HR / Admin Records	Working patterns, contractual sitting days	Manual entry by RSU users	High
2	Inbound	eLinks (Judicial Database)	Judge profiles, roles, base locations	Manual (automated import is a stated NFR, not yet implemented)	High
3	Inbound	Court Listing Systems	Planned judicial activity (how judges spend the day)	Manual copy / data entry	Medium
4	Inbound	Court Staff	Sitting confirmations, actual work types, absence requests	Manual entry via JI UI	High
5	Outbound	JFEPS / Finance System	Fee-paid judge payment files	JFEPS-compatible Excel export, emailed to Payment Authoriser	Critical
6	Outbound	Liberata	Payment schedules	Email (forwarded by Payment Authoriser)	Critical
7	Outbound	DA&I (Data, Analysis & Insight)	Sitting days, utilisation, vacancy & absence analysis	Excel / PDF report exports	High
8	Outbound	HMCTS Email Infrastructure	Itineraries, booking confirmations, absence notifications, payment files	Automated email (some overnight batch)	High
9	Both	JFEPS (Reconciliation)	Payment status, discrepancies between bookings and payments	Manual flagging in JI after finance confirmation	Medium
10	Platform	OPT / Oracle APEX	Runtime, authentication, shared assets, session management	Tightly coupled platform dependency	Critical

For detailed descriptions of each dependency, see the sections below.

---

These are external systems or sources from which JI receives or imports data.

1. HR / Administrative Records

Attribute	Detail
Source system	HR systems / administrative records (specific system not named in documentation)
Data consumed	Judge working patterns, contractual sitting days, part-time arrangements, agreed working arrangements
Data type	Reference / configuration data
Mechanism	Manual entry by RSU users into JI. No automated integration.
Frequency	As changes occur (e.g. new judge, change to part-time, base court transfer)
Criticality	High - working patterns are the foundation for generating judge itineraries and sitting targets

Note: JI is explicitly not the system of record for HR or employment contracts. It reflects working patterns that have already been agreed elsewhere.

2. eLinks (Judicial Database)

Attribute	Detail
Source system	eLinks - the Judicial Database
Data consumed	Judiciary data: judge names, details, roles, base locations, status
Data type	Master / reference data
Mechanism	The SRS states "The system shall support eLinks integration for importing judiciary data" (NFR-3). However, the current technical mechanism, frequency, and detailed data mapping are not described - it is a stated requirement, not a fully implemented integration. Currently data is manually copied.
Frequency	Unknown / manual
Criticality	High - judge profile data is foundational to all JI operations

Note: The training documentation states that once the new Judicial Database replacement is complete, processes for updating JI from it will be examined. Currently all judge data maintenance is done manually and users must keep both systems updated.

3. Listing Systems (Courts)

Attribute	Detail
Source system	Court listing systems (e.g. systems used by courts for case listing)
Data consumed	Planned judicial activity data - how judges plan to spend their working day
Data type	Operational / transactional data
Mechanism	Manual - data is copied from listing systems or entered manually by HMCTS staff, then confirmed after the fact ("recording the actual")
Frequency	Daily (courts are encouraged to confirm sittings daily)
Criticality	Medium - provides the "actuals" that drive utilisation reporting and payment processing

Note: There is no direct system-to-system integration between JI and core case management systems (CaseMan, FamilyMan, Common Platform). This is explicitly stated in the documentation.

4. Court Staff (Manual Confirmation Data)

Attribute	Detail
Source system	Local court offices
Data consumed	Confirmation of sittings and bookings (did the sitting actually occur, session duration, actual work type), absence requests
Data type	Operational / transactional data
Mechanism	Manual entry via JI user interface
Frequency	Daily (recommended), at minimum before monthly verification deadline
Criticality	High - confirmed data drives payment exports and MI reporting

---

These are external systems or processes that consume data produced by JI.

5. JFEPS / Finance System (Judicial Fee Payments)

Attribute	Detail
Destination system	JFEPS (Judicial Fee Payment System)
Data produced	Payment data for fee-paid judges derived from confirmed bookings: judge details, court codes, dates, session types, booking IDs, fee amounts
Data type	Financial / transactional data
Format	JFEPS-compatible Excel export files
Mechanism	JI generates Excel files, validates data before export (dates, court codes, booking IDs), and emails the file to designated Payment Authorisers. The authoriser reviews, approves, and manually uploads to JFEPS.
Frequency	Typically weekly
Criticality	Critical - this is the primary mechanism for paying fee-paid judges in Crown Courts. Without JI, courts would need to manually create each payment.

Note: JI does not process payments directly. It does not store or expose judge bank details or sensitive financial information - those remain in the finance system.

6. Liberata (L!BERATA) - Payment Processing

Attribute	Detail
Destination system	Liberata (payment processing partner)
Data produced	Payment schedules for fee-paid judicial sittings
Data type	Financial / transactional data
Format	Payment schedule (via email, forwarded by Payment Authoriser)
Mechanism	JI generates payment schedule -> sent to Payment Authoriser -> authoriser reviews and forwards to Liberata
Frequency	Weekly
Criticality	Critical - Liberata processes the actual fee payments

7. DA&I (Data, Analysis & Insight) - Management Information

Attribute	Detail
Destination system	DA&I team systems / analytics platforms
Data produced	Sitting day data, judicial utilisation statistics, vacancy analysis, booking analysis, absence analysis
Data type	Aggregated management information
Format	Excel and PDF exports from JI report screens; manual extraction via spreadsheets
Mechanism	Export-based - DA&I extracts and transforms JI data into management information. Reports are exported via browser copy-paste to Excel or PDF download.
Frequency	As required for reporting cycles
Criticality	High - JI is currently the primary source of sitting day data for Civil, Family, and Crown Courts. DA&I aggregates this to produce MI on planned and actual sittings.

8. Email Infrastructure (HMCTS)

Attribute	Detail
Destination system	HMCTS email infrastructure
Data produced	Itinerary emails to judges and staff, absence acknowledgement notifications, booking confirmation/cancellation notifications, payment export files to Payment Authorisers, alerts to court staff
Data type	Notifications and document distribution
Mechanism	Automated email sending from JI (some immediate, some via overnight batch process)
Frequency	Event-driven (on booking, absence, cancellation, payment export)
Criticality	High - operational communications depend on email delivery

---

9. Payment Reconciliation (JFEPS -> JI)

Attribute	Detail
Systems	JFEPS / Finance System <-> JI
Data exchanged	Reconciliation data: which payments have been made, which remain pending, discrepancies between JI-generated payment requests and finance confirmations
Data type	Financial reconciliation
Mechanism	Finance users manually flag payments as reconciled in JI once confirmation is received from JFEPS. No automated data feed back into JI from finance.
Frequency	Ongoing as payments are processed
Criticality	Medium - ensures bookings are not double-paid and discrepancies are tracked

---

10. OPT / Oracle APEX Platform

Attribute	Detail
System	One Performance Truth (OPT) platform
Dependency type	Runtime platform
Services consumed	Oracle APEX runtime and authentication, shared JavaScript/CSS assets (opt.common.js, opt.ji.js), session management and timeout controls, APEX page templates, session timeout plug-ins
Criticality	Critical - JI cannot operate without the OPT APEX platform

Note: The OPT platform is unsupported legacy technology. There is an active initiative to transition OPT-based applications under DTS management, with the Board endorsing full replacement as the strategic direction.

---

The numbered badge in the top-right of each box matches the # column in the At a Glance table above, so the diagram can be walked through in sequence (1 → 10).

---

1. Heavy reliance on manual data entry - Most inbound data flows are manual. Judge details are manually maintained from HR records and eLinks. Sitting confirmations are manual. Working patterns are manually entered.

2. No case management system integration - JI explicitly does not integrate with CaseMan, FamilyMan, or Common Platform. It operates at the judicial scheduling level only, not at case/hearing level.

3. Export-based outbound integration - All outbound data flows are file-based (Excel, PDF) or email-based. There are no API integrations.

4. JFEPS is the most critical integration - The payment export to JFEPS is the most operationally critical data dependency. Crown Courts rely on this to pay fee-paid judges.

5. Tribunals gap - JI currently does not cover Tribunals, which is a significant data gap. Tribunal sitting data is collected manually via spreadsheets managed by different Chamber Presidents' Offices.

6. Future integration needs - The Actuals programme and Scheduling & Listing (S&L) reforms require JI data and integration, which the current export-based model cannot easily support.

---

This analysis is based on the following input documents:

• High Level Capabilities JI.docx
• JI Functional and Non Functional Requirements.docx
• Judicial Itineraries High Level Requirements.docx
• Judicial Itinerary KB.docx
• OPT JI Training Brief DRAFT 02.doc
• UCD resource request.docx