Managing the content lifecycle

Before adding content to any toolkit, you should ensure that at, as a minimum, parts 1 and 2 of the Requesting a new Right Decisions toolkit standard operating procedure have been completed and that the forms have been approved by the Right Decision Service team.

This includes confirming that: 

1) The organisation has reviewed and approved the terms and conditions of use of the Right Decisions Platform (see About this site section within the RDS main navigation menu.)

2) The proposal to develop the toolkit has been approved by the identified governance structure and process.

3) Key roles in authoring, reviewing, approving, uploading and editing content have been defined.

4) You have documented roles and responsibilities for authoring, review and approval of new content, content changes and content withdrawal.

5) You have documented processes in place for:

• Scheduled review and approval for new content – this includes the content itself and its presentation via RDS. 
• Review and approval of proposed changes to content – this includes the content itself and its presentation via RDS.

Before the initial version of the toolkit goes live, you should also have submitted and had approved the Part 3 form within the Requesting a new Right Decisions toolkit standard operating procedure. 

You should also have in place:

• A timetable for scheduled review of content
• A process for proposal and approval of content withdrawal
• A process for advising users of changes to content – e.g. via announcements, notifications or an area within the toolkit where changes are logged.

It is important to build into these governance processes any exceptional requirement for urgent changes to be made and disseminated quickly.

You should identify the named editors who will be involved in content management, and define the appropriate level of editorial permissions. The RDS team or a local manager with user management permissions for the RDS platform can support you by setting up user profiles and assigning the appropriate permissions.

Permission rights can be assigned at the following levels:

• Editor – can create and edit standard text and media content but not publish.
• Publisher – can publish standard text and media content to web.
• Pathway editor – can create, edit and publish visual pathways.
• QAB editor – can create and edit question and answer pathways.
• QAB publisher – can publish question and answer pathways to web.
• Shared content editor – can create and edit shared content.
• Shared content publisher – can publish shared content.
• Shared content viewer – can view but not edit or publish shared content.
• Application manager – can publish content to app.

All editors should receive training at the level appropriate for their permissions before starting work on content editing.

One to one or group training sessions can be scheduled with the RDS team by emailing his.decisionsupport@nhs.scot. Alternatively, you may be able to arrange training with experienced editors within your own organisation.

An RDS toolkit comprising online and blended learning resources is being prepared to support training requirements across the system.

Always copy and paste content from original files as plain text then format in RDS. This is to avoid hidden code in Word docs, PDFs etc. from altering or omitting content. Use a text editor such as Notepad and always ask toolkit owners/ content authors to carefully check content for accuracy before signing it off.

Approvers should confirm content readiness for publication from three perspectives:

• Subject matter expertise
• Proof reading of content
• Assignment of editorial information – see below.

All content added to the Right Decisions platform should be assigned the following editorial information. For standard text-based content, this should be entered in the Editorial tab for content nodes. For visual pathways and QAB pathways, this information should be entered in a content page associated with the resource:

• Author (s)
• Author email addresses
• Approver name
• Named reviewer(s)
• Reviewer email address(es). It may be appropriate to choose a team or administrative email address which can act as a central coordinating point to manage reviews, reducing dependency on contacting named individuals who may change role, go on leave etc.
• Version number
• Date of last review – in the case of new content, this will be the publication date
• Date of next scheduled review.

Identifying content due for review

Automated email alerts will be sent to the designated reviewer email address at 90 days and 30 days before the scheduled review date and at 7 days after the scheduled review for standard text-based content. Timing and wording of these automated alerts are defined globally for the RDS as a whole.

The national RDS team will also run 6 monthly reports to identify all content past its review date, and will contact the reviewers of expired content. Reviewers will be encouraged to action the review process, or to make a corporate decision that the content is safe and appropriate for continued use, as outlined below.

Local review reports

Local RDS administrators can also be assigned permission to run reports of local content past its review date. At local level, RDS administrators should include in their content withdrawal process the potential to withdraw content if review is not conducted at the scheduled time.

Review actions

At the scheduled review date, reviewers should:

• Organise the content review.
• Document changes as outlined in the Change Control process below.
• Update the next review date information in the Editorial section of the content management system.
• Add to the Notes field in the Editorial section the confirmation that review was carried out, and a brief summary of results. If the review confirms that no changes are needed, this should be documented in the Notes field.

If review cannot be conducted at the scheduled time

If capacity constraints or lack of availability of key individuals means that review cannot be conducted at the scheduled time, the local Senior Responsible Owner or Product Owner should take the following actions:

• Confirm with the appropriate local governance group overseeing the delivery of the toolkit, and/or with relevant subject matter experts whether the content is still safe and appropriate to make available for use. This includes consideration of whether the benefits of continuing to provide access to the content outweigh the potential risks of content not being up to date.  If the content is deemed still appropriate for use, the outcome of this process should be documented in the Notes field of the Editorial section. The next scheduled review date should then be updated.
• If the content is not deemed safe and appropriate for use at this time, or if the local governance group cannot reach a decision, the procedure for content withdrawal outlined below should be followed. Content should be unpublished or hidden until review can be carried out. This decision should be documented in the Notes field.

Follow up if no response

 If no response is received or no action taken in response to the review alert, the RDS team may contact the local SRO or Product Owner. If necessary, the RDS team may consult on the risks associated with continued delivery of out of date content. They may take the decision to withdraw content and to remove editorial rights from local content owners until a commitment can be made to review and updating.  The RDS team will advise the appropriate local contact of this decision.

Requests for changes to toolkit content (e.g. updates, additions, corrections, deletions) can come from the authors and editors, from colleagues or from toolkit users.

All proposed changes to content and approval or rejection of these changes should be formally documented and dated within a Change Request form (see example) and retained on file for future reference.

Change requesters should be notified of the outcome of their request.

Once approval is documented, the changes can be made, approved and published within the RDS.

Version number should be updated within the Editorial tab, and a note of any substantial changes recorded in the Notes field.

End-users should be notified of substantive changes – e.g. via announcements, push notifications, and/or a record of changes kept in a “latest updates” section of the toolkit.

If alternative versions of RDS content are held locally in another format – e.g. Word or PDF files – it is essential that all versions are updated synchronously and that version control is kept consistent.

Content withdrawal may be temporary (e.g. pending future review) or permanent (e.g. content no longer relevant or complete rewrite needed.)

As outlined above, a process should be documented for each toolkit for proposal and approval of content withdrawal.

When the decision to withdraw content is approved, the content should be unpublished or hidden from the web. This action should be recorded in the Notes field of the Editorial section and a statement ‘(Content withdrawn)’ added to the content title.

Users should be informed of withdrawal of the content and of the reasons for withdrawal e.g. via announcements, push notifications, and/or a record of changes kept in a “latest updates” section of the toolkit.

Withdrawn information should be moved to the archive after a period equivalent to two scheduled review cycles.

To archive digital content in this context means to store it apart from the live toolkit in a safe and central location. This means it will no longer be visible to users, but the authors can still access and/or restore it in future if required. For example, an unpublished “Archived version” toolkit can be created within the RDS, and archival content moved to that location.

Authors should produce a retention policy for archived content, referencing relevant local and national policies on record retention, destruction and archiving.

Approval of the decision to archive content should be documented within a Change Request form, and should be recorded within the Notes field of the content. The phrase ‘(Archived)’ should be added to the end of the title.