We're please to announce the 9.26 release of SProc, bringing you several new enhancements and defect fixes.
New developments
External referrer progress tracking dashboard
What's new
External Referrers (GPs, District Nurses, and other healthcare professionals) can now track the progress of submitted CHC referrals and receive automated email notifications at key milestones throughout the assessment process.
Key benefits
Complete visibility: View all submitted referrals in a new 'All' tab on the dashboard, not just those pending completion.
Better patient communication: Keep patients and families informed with real-time updates on assessment progress.
Timely notifications: Receive automatic emails when referral status changes, assessors are allocated, appointments are scheduled, or decisions are made.
Improved coordination: Know exactly when additional information is required or when key milestones are reached.
How it works
Dashboard enhancement: New All tab displays all your submitted referrals with status information.
Email notifications include:
Referral status changes, such as from Pending QA to Eligible for Assessment.
Assessor allocation with contact details.
Assessment appointment scheduling with date, time, and location.
CHC eligibility decisions with outcomes and dates.
Each email includes a direct link to view the referral in the system.
Team members also receive notifications for referrals submitted by colleagues.
How to access
Log in to the Patient Portal and navigate to your dashboard to see the new All tab. Email notifications are sent automatically - no configuration required.
Cost recovery service agreements with negative values
What's new
Commissioning Officers can now create and manage cost recovery service agreements with negative rate values, eliminating the need for manual intervention from Access support staff.
Key benefits
Self-service processing: Create cost recovery service agreements without escalating to Access staff, reducing processing delays.
Improved workflow: Configure cost recovery functionality at Company/Supply Category/Service Template level for complete control.
Comprehensive lifecycle management: Handle creation, change orders, and manual edits with proper validation and controls.
Enhanced reporting: Filter and report on cost recovery service agreements separately from standard agreements.
How it works
Enable the feature: System administrators activate the 'SA - CSA Enable Cost Recovery' rule at Company/Category/Service Template level (disabled by default).
Create cost recovery SAs: When creating service agreements via the CSA wizard, select Cost Recovery as the Service Agreement Type.
Enter negative rates: System accepts negative values (e.g., -£50.00) and automatically sets Service Cost, Supply Bill, and Client Charge to the negative value.
Type protection: Service Agreement Type cannot be changed after creation - maintaining data integrity.
Change orders: All change orders maintain the cost recovery designation and validation rules.
⚠️ Important:
Existing service agreements default to Standard type and cannot be retrospectively changed to Cost Recovery.
Cost Recovery service agreements require negative rate values; positive values are not permitted.
The Service Agreement Type field is available in custom reports and list page columns.
How to access
Access Adam System administrators can enable the feature upon request via Admin Tools by configuring the 'SA - CSA Enable Cost Recovery' rule. Once enabled, commissioning officers will see the Service Agreement Type field in the CSA wizard.
Patient data now available via Evo Data Engine API
The Evo Data Engine API now provides comprehensive access to patient data through a new dedicated endpoint, enabling external systems, business intelligence tools, and reporting platforms to retrieve patient information programmatically.
Key benefits
Complete patient data access: Retrieve full patient information from the patient_view data source via API, including demographics, care details, and commissioning information.
Secure and controlled access: Built-in permission validation ensures only authorised API keys with Access Data Engine Patient Data permissions can access patient information.
Robust data protection: Automatic filtering of sensitive and restricted patient records maintains Caldicott principles and data protection standards.
Company-level data scoping: All data is automatically scoped to your organisation, ensuring complete data segregation between companies.
Flexible filtering: Optional filtering by Organisation Type enables targeted data retrieval for specific commissioning arrangements.
Technical details
Endpoint: GET /AccessDataEngine/Patients.
Authentication: Requires valid API credentials with Access Data Engine Patient Data permission enabled.
Response: Returns comprehensive patient data from the patient_view data source.
Filtering: Supports optional Organisation Type filtering for targeted data retrieval.
Data protection: Sensitive and restricted patients are automatically filtered from API responses, maintaining consistency with existing SProc UI and reporting behaviour.
Who benefits
Business Intelligence teams: Integrate patient data into analytics platforms, dashboards, and custom reporting solutions.
Commissioners: Access patient information for strategic planning, capacity management, and service delivery monitoring.
Finance teams: Retrieve patient data for financial analysis, forecasting, and budget planning.
System integrators: Build custom applications and workflows using live patient data.
Data analysts: Extract patient data for statistical analysis and performance monitoring.
Get started
Ensure your API key has the Access Data Engine Patient Data permission enabled.
Make GET requests to /AccessDataEngine/Patients.
Optionally filter by Organisation Type to retrieve specific patient cohorts.
Process the returned patient data according to your integration requirements.
Contact your system administrator or Access support team for API key configuration assistance and technical documentation.
Data governance and compliance
⚠️ Important: All existing data protection, patient confidentiality, and Caldicott principles apply to API data access. Sensitive and restricted patient records are automatically filtered from API responses to maintain data governance standards. Ensure your use of patient data via the API complies with your organisation's information governance policies and relevant data protection legislation.
Data Engine API Endpoints - Service Agreement Cost and Subjective Codes
What's new
Two new Data Engine API endpoints are now available for retrieving service agreement financial coding information, supporting enhanced financial reporting and integration with external finance systems.
New API Endpoints
/AccessDataEngine/ServiceAgreementCostCodes - Retrieves cost code allocations for service agreements.
/AccessDataEngine/ServiceAgreementSubjectiveCodes - Retrieves subjective code classifications for service agreements.
Key benefits
Enhanced financial integration: Programmatic access to financial coding information for external accounting and finance systems.
Improved financial reporting: Support for detailed financial analysis and cost allocation reporting.
Secure access: Authenticated API access with appropriate permission controls.
Complete data visibility: Returns all fields that Client Administrators can see in the SProc UI, including service agreement reference identifiers (SA Text Num/ID).
Technical details
Based on existing Service Agreement data structures for consistency.
Includes service agreement reference identifiers for linking to parent records.
Returns data visible to Client Administrators in the standard SProc interface.
Supports financial coding validation and reconciliation processes.
Who can use this
Authenticated API users with appropriate permissions can access these endpoints for integration with external finance systems, accounting platforms, and financial reporting tools.
Patient clinical data now available via Evo Data Engine API
The Evo Data Engine API now provides access to comprehensive patient clinical data through two new dedicated endpoints, enabling external systems and reporting platforms to retrieve patient notes and diagnosis information programmatically.
Key benefits
Clinical data access: Retrieve patient notes and diagnosis information from the associated data views via API, supporting comprehensive clinical reporting and analysis.
Flexible organisation filtering: Patient notes endpoint supports optional filtering by Organisation Type, enabling targeted data retrieval for specific commissioning arrangements with proper null-value handling.
Secure data handling: Built-in permission validation ensures only authorised API keys with Access Data Engine Patient Data permissions can access clinical information.
Data protection compliance: Automatic filtering of sensitive and restricted patient records maintains Caldicott principles and NHS data governance standards.
Company-level scoping: All data is automatically scoped to your organisation, ensuring complete data segregation.
Comprehensive clinical view: Access both structured diagnosis data and detailed patient notes to support care planning and clinical analysis.
Technical details
Patient Notes Endpoint: GET /AccessDataEngine/Patients/Notes
Returns comprehensive patient notes from the associated view.
Supports optional Organisation Type filtering with null-inclusive logic (matches specified org type OR null org type).
Filtering applies only to the note record's organisation type, matching existing system logic.
Patient Diagnoses Endpoint: GET /AccessDataEngine/Patients/Diagnoses
Returns full list of patient diagnoses from the associated view.
Provides structured diagnosis data for clinical reporting.
Authentication: Both endpoints require valid API credentials with Access Data Engine Patient Data permission enabled.
Data protection: Sensitive and restricted patient data is automatically filtered from all API responses, maintaining consistency with existing SProc UI and reporting behaviour.
Who benefits
Clinical teams: Access patient notes and diagnosis data for care planning, clinical reviews, and multidisciplinary team meetings.
Commissioners: Retrieve clinical information for service planning, capacity management, and quality monitoring.
Business Intelligence teams: Integrate clinical data into analytics platforms for outcome analysis and performance monitoring.
Care Coordinators: Access comprehensive patient clinical information for case management and care coordination.
Quality Assurance teams: Extract diagnosis and notes data for clinical audit and quality improvement initiatives.
System integrators: Build custom clinical dashboards and reporting solutions using live patient data.
Getting started
Ensure your API key has the 'Access Data Engine Patient Data' permission enabled.
Make GET requests to /AccessDataEngine/Patients/Notes or /AccessDataEngine/Patients/Diagnoses.
For patient notes, optionally filter by Organisation Type to retrieve specific cohorts.
Process the returned clinical data according to your integration requirements.
Contact your system administrator or Access support team for API key configuration assistance and technical documentation.
Data Governance and Clinical Safety
⚠️ Important: All existing data protection, patient confidentiality, and Caldicott principles apply to API data access. Sensitive and restricted patient records are automatically filtered from API responses to maintain data governance standards. Clinical data accessed via the API must be handled in accordance with:
Your organisation's information governance policies.
NHS data security and protection requirements.
Relevant data protection legislation (UK GDPR).
Professional clinical confidentiality standards.
Ensure appropriate clinical governance oversight for any use of patient clinical data accessed through the API.
Patient safety alerts now available via Evo Data Engine API
The Evo Data Engine API now provides access to patient alerts through a dedicated endpoint, enabling external systems, care management platforms, and clinical dashboards to retrieve critical patient safety information programmatically.
Key benefits
Patient safety information access: Retrieve comprehensive patient alerts from the associated data view via API, supporting proactive safety management and clinical decision-making.
Critical information visibility: Access alerts that may impact care planning, service delivery, and safeguarding requirements.
Secure and controlled access: Built-in permission validation ensures only authorised API keys with Access Data Engine Patient Data permissions can access alert information.
Data protection compliance: Automatic filtering of sensitive and restricted patient records maintains Caldicott principles and NHS data governance standards.
• Company-Level Scoping: All data is automatically scoped to your organisation, ensuring complete data segregation
• Enhanced Care Coordination: Integrate patient safety alerts into external care coordination platforms and clinical workflow systems
Technical details
Endpoint: GET /AccessDataEngine/Patients/Alerts.
Authentication: Requires valid API credentials with Access Data Engine Patient Data permission enabled.
Response: Returns comprehensive patient alerts from the associated view including alert types, dates, and relevant safety information.
Data protection: Sensitive and restricted patient data is automatically filtered from API responses, maintaining consistency with existing SProc UI and reporting behaviour.
Who benefits
Clinical teams: Access critical patient safety alerts to inform care planning and clinical decision-making.
Safeguarding officers: Monitor patient safety alerts for safeguarding risk identification and management.
Care coordinators: Integrate alert information into care coordination workflows to ensure appropriate service delivery.
Quality Assurance teams: Extract alert data for safety monitoring, incident analysis, and quality improvement initiatives.
Business Intelligence teams: Include patient safety alerts in analytics platforms for trend analysis and safety reporting.
System integrators: Build custom clinical dashboards and care management applications using live patient alert data
Getting started
Ensure your API key has the 'Access Data Engine Patient Data' permission enabled.
Make GET requests to /AccessDataEngine/Patients/Alerts.
Process the returned alert data according to your integration requirements.
Implement appropriate safety protocols for handling and acting upon alert information.
Contact your system administrator or Access support team for API key configuration assistance and technical documentation.
Patient Safety and Data Governance
⚠️ Important: Patient alerts contain critical safety information that must be handled with appropriate clinical governance. All existing data protection, patient confidentiality, and Caldicott principles apply to API data access. Sensitive and restricted patient records are automatically filtered from API responses. Ensure that:
Alert information accessed via the API is reviewed by appropriately qualified clinical staff.
Your organisation's safeguarding and clinical governance policies are followed.
NHS data security and protection requirements are met.
Relevant data protection legislation (UK GDPR) is complied with.
Professional clinical and safeguarding standards are maintained.
Organisations using patient alert data via the API must maintain appropriate clinical governance oversight and ensure timely review and action on safety-critical information.
RAG status indicator for overdue requirements
What's new
Requirements now display a RAG (Red/Amber/Green) status indicator for overdue visibility, providing brokers and commissioning officers with immediate visual cues for workflow prioritisation.
Key benefits
Instant urgency assessment: Quickly identify which requirements need immediate attention based on overdue status.
Consistent visual language: Uses the same RAG status styling as referral records for system consistency.
Improved workflow management: Prioritise workload more effectively with clear overdue indicators on both list and detail pages.
Accessible design: Visual indicators include text labels (Yes/No) alongside colour coding for accessibility.
How it works
Is Overdue field: Displays on both requirement list pages and detail pages.
Green status: Requirement is due today or not yet overdue.
Red status: Requirement is overdue by 1 day or more (when today's date is past the requirement start date).
Styling: Consistent with existing referral Clock RAG status indicators.
Where to find it
The Is Overdue field is visible on requirement list pages and individual requirement detail pages for all users with permissions to view requirements.
Data Engine API Endpoints - Service agreement custom codes and rates
What's new
Two new Data Engine API endpoints are now available for retrieving detailed service agreement configuration and rate information, enhancing data integration capabilities for external reporting and analytics systems.
New API Endpoints
/AccessDataEngine/ServiceAgreementCustomCodes - Retrieves service agreement custom code configurations.
/AccessDataEngine/ServiceAgreementRates - Retrieves detailed service agreement rate information including rate elements and financial data.
Key benefits
Enhanced data integration: Programmatic access to service agreement configuration and financial data.
Improved reporting: Support for external business intelligence and financial reporting systems.
Secure access: Authenticated API access with appropriate permission controls.
Client-appropriate data: API endpoints respect user permissions and only expose data visible to Client Administrators in the SProc UI.
Technical details
Based on existing custom report views for consistency and accuracy.
Includes service agreement reference identifiers (SA Text Num/ID) for linking to parent records.
Returns only fields that Client Administrators can see in the standard SProc interface.
Supports service agreement rate validation and financial reporting capabilities.
Who can use this
Authenticated API users with appropriate permissions can access these endpoints for integration with external systems, reporting tools, and data analytics platforms.
Service receipt approval - Week end date validation
System Administrators can now configure a new approval condition for Service Receipts based on a days/weeks threshold from the week end date. This allows organisations to automatically flag SRs that are created outside their defined timeframe, ensuring better control over late submissions whilst maintaining financial accuracy.
Key features
Configurable threshold in days or weeks.
Comparison against week end date.
Independent from existing weeks back rules.
Simple enable/disable toggle.
Assessment cancellation reason tracking
When cancelling assessments, users can now record why the assessment was cancelled by selecting from a dropdown list of configurable cancellation reasons. This enhancement ensures proper audit trails and enables organisations to analyse cancellation patterns for process improvement.
What's new
When you populate the Date Cancelled field on an assessment, a Cancellation Reason dropdown now appears requiring you to select why the assessment is being cancelled. You can also provide optional comments to give additional context. The cancellation reason is automatically logged and timestamped, creating a complete audit trail.
Key capabilities
Mandatory reason selection: Must select a cancellation reason when cancelling an assessment.
Configurable reasons: Your organisation defines the cancellation reasons available in the dropdown.
Optional comments: Add up to 4000 characters of additional context.
Automatic audit trail: Every cancellation reason is automatically logged with timestamp.
Simple interface: Fields appear directly on the assessment form when Date Cancelled is populated.
Benefits
Better data quality: Mandatory reason ensures all cancellations are properly documented.
Audit compliance: Complete audit trail for all assessment cancellations.
Operational insights: Analyse why assessments are being cancelled to identify trends.
Consistent experience: Works the same way as referral cancellations.
Enhanced change orders list clarity
The change orders list display on service agreements has been improved to provide better clarity about which change orders require action.
What's changed
Accept/Decline and Approve/Reject action columns now only display when actions are genuinely available.
Change orders in pending implementation status no longer show action buttons.
Completed change orders no longer show action buttons.
Contact types - Company-level configuration
What's new
Contact Types can now be configured at the company level, giving Client Administrators control over which contact types are visible and how they're named within their organisation.
Key benefits
Reduced clutter: No longer see all 300+ system-wide contact types - only the ones relevant to your organisation.
Customisable names: Rename contact types to match your organisation's terminology.
Better control: Hide contact types you don't use to streamline dropdown lists.
How to access
Client admins can manage contact types via:
Click Admin then My Company.
Click Admin then CMS Configuration.
Click Contact Types.
📌 Note: All existing contact types have been automatically migrated to company-level configuration. Your historical data remains unchanged.
Edit contact types directly in CMS configuration
Organisation Administrators can now edit existing Contact Type values directly within CMS Configuration, eliminating the need to deactivate and recreate Contact Types when terminology needs updating.
Key benefits
Simplified contact type management: Update Contact Type names directly without disrupting existing data or historical references.
Data integrity: Contact Type IDs remain unchanged when editing, maintaining all existing relationships and historical records.
Improved terminology management: Easily update Contact Types to reflect current terminology, organisational changes, or service evolution.
Reduced administrative burden: No longer need to deactivate old Contact Types and create new ones, simplifying maintenance workflows.
Organisation-level control: Edits apply only to your organisation's Contact Types, maintaining independence between organisations.
Audit trail: All Contact Type edits are logged with date, time, and user information for governance and compliance.
How it works
To edit a Contact Type:
Navigate to CMS Configuration then [General Information] Contact Types.
Open the contact type you wish to edit.
Modify the Contact Type field as needed.
Save your changes.
The system automatically updates the 'Date Updated' and 'Updated By' fields to record when and who made the change, whilst preserving the Contact Type ID to maintain data integrity.
Built-in validation
The system includes protective validation to ensure data quality:
Duplicate prevention: You cannot save a Contact Type with a name that already exists within your organisation.
Required fields: Contact Type names cannot be blank.
Clear error messages: Helpful validation messages guide you if issues are detected.
Who benefits
Organisation administrators: Maintain accurate Contact Type terminology without complex workarounds.
CMS configuration managers: Keep configuration data current and aligned with organisational terminology.
Care coordinators: Benefit from up-to-date Contact Type labels that reflect current service arrangements.
Data Quality teams: Maintain consistent terminology across the system without creating duplicate or redundant entries.
Important notes
This functionality applies to organisation-level Contact Types only.
Each organisation maintains independent Contact Types – edits made in your organisation do not affect other organisations.
Contact Type IDs remain unchanged to preserve all existing data relationships.
All edits are recorded in the audit trail for governance purposes.
Requires Client Administrator permissions with CMS Configuration access.
Use cases
Common scenarios where this enhancement is valuable:
Updating terminology to reflect current NHS or organisational standards.
Correcting spelling or formatting in Contact Type names.
Adding clarification to Contact Types (e.g., changing 'Family Member' to 'Family Member / Relative').
Aligning Contact Types with service redesign or organisational restructuring.
Consolidating similar Contact Types through careful renaming.
Configure custom code display in Offers list
What's new
Access administrators can now configure whether custom codes (external codes) from requirements are automatically displayed on offers, providing customers and providers with essential reference information that links commissioning requests to service offers. This new configurable feature enables organisations to maintain traceability between requirements and offers whilst giving flexibility to enable or disable the functionality based on workflow needs.
Key benefits
Flexible configuration control: Enable or disable custom code display at Company or Supply Category level using the new 'RQ - Copy Custom Code To Offer External ID' preference, allowing granular control over which service categories include custom codes on offers.
Enhanced offer information for customers: Customers and providers viewing offers can now see relevant custom code information that was originally entered on the requirement, providing additional context and reference details for brokerage decisions.
Improved requirement-to-offer traceability: Custom codes copied from requirements to offers maintain clear reference links between commissioning requests and service offers, supporting audit trails and workflow tracking.
Streamlined brokerage workflows: Automatically populate offer external IDs with requirement custom codes when enabled, reducing manual data entry and ensuring consistency between requirements and offers.
Administrative control: Organisations can choose whether to use this functionality based on their specific commissioning and brokerage processes, with the feature disabled by default to avoid impacting existing workflows.
How it works
Configuration
Access System administrators navigate to Preferences at Company or Supply Category level.
Locate the new RQ - Copy Custom Code To Offer External ID preference.
Enable the preference to activate custom code copying (disabled by default).
Operational flow
When the preference is enabled, users enter custom codes on requirements as normal.
When an offer is generated from that requirement, the custom code is automatically copied to the offer's External ID field.
Customers and providers viewing the offer can see the custom code information.
When the preference is disabled, no custom codes are copied to offers (existing behaviour is maintained).
Technical details
Configuration location: Preferences > Company or Supply Category level
Preference name: RQ - Copy Custom Code To Offer External ID
Default setting: Disabled (value = 0)
Scope of impact
When enabled at company level: Applies to all requirements and offers for that company.
When enabled at supply category level: Applies only to requirements and offers for that specific supply category.
Who benefits
Brokerage teams: Maintain reference links between requirements and offers with automatically populated external IDs.
Commissioning officers: See custom code information on offers without manual entry, reducing data entry burden.
Finance teams: Use custom codes on offers for financial tracking and reporting purposes.
Customers/Providers: View relevant custom code information when reviewing offers.
System administrators: Control custom code visibility based on organisational workflow requirements.
Use cases
Scenario 1 - NHS contact references
A commissioning team uses custom codes to track NHS contract references on requirements. With this feature enabled, the NHS contract reference automatically appears on offers sent to providers, ensuring they can identify which contract framework applies.
Scenario 2 - Budget code tracking
An organisation uses custom codes to track budget codes on requirements. When offers are generated, the budget code is automatically included, allowing finance teams to reconcile offers against budget allocations without manual lookup.
Scenario 3 - Service category specific codes
An organisation wants custom codes to appear on offers for residential care services but not for domiciliary care services. They enable the preference at the Residential Care supply category level only, giving them granular control.
Getting started
⚠️ Important: This feature must be configured by an Access Administrator only. Customers do not have access to the preferences function and should contact Access support to request this feature be enabled.
New offers generated after enabling the preference will include custom codes. Existing offers are not retrospectively updated.
Support and further information
For questions about configuring this feature or to discuss the picklist display enhancement, contact Access support via your usual channels.
Configuration assistance: Your system administrator or Access support team can help configure the preference at the appropriate organisational level.
Feature enhancement requests: If your organisation requires custom codes with picklist values to display as text rather than IDs, please raise an enhancement request with Access support.
Data Governance considerations
When enabling custom code display on offers:
Ensure custom codes entered on requirements contain appropriate information for external visibility.
Review data quality of custom code fields to maintain professional presentation on offers.
Consider which supply categories require custom code visibility and configure accordingly.
Document your organisation's use of custom codes on offers in internal procedures.
This feature provides flexibility whilst maintaining data integrity and giving organisations control over what information is shared with customers and providers via offers.
Defect fixes
Bug Fix: S117 Referral Creation with Blank NHS ID
Issue resolved
Fixed an error that occurred when creating S117 (external only) referrals where a blank NHS ID was entered, resulting in system errors and preventing referral creation.
What was fixed
System now properly validates NHS ID fields during referral creation.
Prevents blank or incomplete NHS ID entries from causing conversion errors.
Improved error handling when NHS ID field is left empty or deleted after completion.
Enhanced validation for patient searches with various NHS ID format variations.
Impact
External referrers and internal users can now create S117 referrals without encountering system errors related to blank or invalid NHS ID values. The system provides proper validation and prevents data quality issues.
Bug Fix: Funding Start and End Date Fields Missing from Decision Entry
Issue resolved
Fixed an issue where the Funding Start Date and Funding End Date fields were not appearing when entering a decision on a CHC assessment referral in the CMS system.
What was fixed
Restored visibility of Funding Start Date and Funding End Date fields when selecting approved funding decisions.
Fields now correctly appear in the decision wizard when configured to do so.
Resolved issue affecting both Production and Preview environments.
Impact
CHC practitioners and assessors can now properly record funding start and end dates when making eligibility decisions, ensuring complete and accurate decision records for approved CHC funding.
User action required
None - the fields will automatically appear as expected when entering decisions where funding is approved, provided the fields are configured to display in the decision wizard.
AACC Report Accuracy Improvement - Duplicate Review Records Resolved
We have resolved an issue in the All-Age Continuing Care (AACC) reporting functionality that was causing duplicate review records to appear in the exported AACC dataset.
Issue resolved
Previously, the AACC report was including multiple review records for the same patient referral when reviews were updated or modified. For example, a single patient referral (e.g., PR12345) could appear with 5 duplicate review records in the AACC103Review tab, when only one review record should be present based on the actual patient referral data in SProc.
The fix
The AACC reporting logic has been updated to ensure that only the most recent review record within the reporting period is included for each patient referral. The fix ensures that:
Review records are correctly deduplicated based on the relationship to the actual patient referral.
Only the latest review within the specified time period is exported per referral.
The AACC report data now accurately reflects the current state of patient reviews as shown in the SProc CMS interface.
Impact
This fix significantly improves the accuracy and usability of the AACC report by:
Eliminating data duplication: Removes hundreds of duplicate review records that were artificially inflating the dataset (e.g., 419 duplicates identified in a single month's report).
Reducing manual data cleansing: Eliminates the need for finance and commissioning teams to manually identify and remove duplicate records before analysis.
Improving reporting efficiency: Significantly reduces the time required to process and validate AACC reports.
Enhancing data quality: Ensures AACC submissions to NHS England accurately represent the organisation's CHC activity without artificial duplication.
Who benefits
Finance teams: Receive accurate AACC datasets without time-consuming manual deduplication.
CHC commissioners: Obtain reliable review activity data for capacity planning and performance monitoring.
Data quality officers: Ensure AACC submissions meet NHS England data quality standards.
Business Intelligence teams: Analyse review activity trends with confidence in data accuracy.
Technical details
The fix modifies the AACC reporting query logic to properly deduplicate review records based on their relationship to patient referrals, ensuring that only the most recent review within the reporting period is included for each referral. This aligns the AACC export data with the review information displayed in the SProc CMS referral interface.
Bug Fix: Downloadable Template Section Restored in Accreditations and Enrolments
Issue resolved
Fixed an issue where the 'Downloadable Template' section was missing from all Accreditation and Enrolment (A&E) pages, preventing suppliers from accessing required process document templates.
What was fixed
Restored the 'Downloadable Template' section on all Accreditation and Enrolment detail pages.
Supplier process document templates are now viewable and downloadable during the A&E process.
Resolved issue affecting all suppliers across the platform.
Impact
Suppliers can now access and download required document templates (such as NHS contract templates) when completing or updating their Accreditations and Enrolments. This removes a barrier that was preventing suppliers from submitting complete A&E documentation.
User action required
None - the Downloadable Template section is now automatically visible on all relevant Accreditation and Enrolment pages.
AACC Report Data Integrity Improvement - ChangeLog Date Overlap Resolved
We have resolved a related issue in the All-Age Continuing Care (AACC) reporting functionality that was allowing overlapping start and end dates in the AACC ChangeLog, which could contribute to duplicate records appearing in the exported dataset.
Issue resolved
The AACC ChangeLog was previously allowing multiple records to have the same end date, which violated the expected data integrity constraint that ChangeLog start and end dates should not overlap. This issue was related to the duplicate review records problem reported by Cambridgeshire and Peterborough ICB.
The fix
The AACC ChangeLog validation logic has been updated to ensure that:
ChangeLog start and end dates do not overlap between records.
End dates are properly managed to maintain data integrity.
The temporal sequencing of change records accurately reflects the history of patient record modifications.
Impact
This fix improves the underlying data quality of the AACC reporting system by:
Preventing date overlaps: Ensures ChangeLog records maintain proper temporal boundaries without overlapping dates.
Improving data integrity: Maintains accurate audit trail of patient record changes over time.
Supporting accurate reporting: Provides a reliable foundation for AACC report generation with correct change history.
Enhancing compliance: Ensures change logging meets NHS England data quality standards for AACC submissions.
Who benefits
Data Quality officers: Ensure AACC ChangeLog data maintains proper integrity constraints.
Finance teams: Benefit from accurate change tracking that supports reliable AACC reporting.
CHC commissioners: Obtain trustworthy historical data for review activity analysis.
System administrators: Maintain data quality standards for AACC submissions.
Technical details
The fix implements proper validation and constraint management for AACC ChangeLog records to prevent overlapping start and end dates. This ensures the change history maintains proper temporal sequencing and supports accurate AACC report generation.
Relationship to previous fix
This fix addresses a related underlying data quality issue that contributed to the duplicate review records problem (Bug #1879175). Together, these fixes ensure comprehensive AACC report accuracy and data integrity.