If your data upload halts and you’re presented with an error along these lines, it means the database rejected some of your data. The application processes data in batches of 900 rows, so this will indicate an issue within the prior 900 rows of data. This may not seem helpful, but this is as accurate as the application can be at this stage. Below are some common specific errors and some common causes:

• "String or Binary Data Would be Truncated"
  • This error indicates that some field(s) within the batch were too long for the database to accept. This will be specific to text fields, most commonly affecting the ckd_gfr "location" field.
• "Error Converting nvarchar to numeric"
  • This error occurs when a text value is given in place of a numeric value. This can only occur with a few specific fields throughout all application database tables. A common cause of this is fields being "out of sync" with the expected layout - usually too many fields within a single row causing a text value to be incorrectly interpreted in place of a numeric field.
• "Check Constraint Failed"
  • This rare error will be caused by some row including an illegal value for ckd_gfr "location type" or "sex" fields. Support values for location types are "I", "O", "R", "X", or any user-mapped types; supported values for sex are "M", "F" and "U".

During application startup (either first-time setup or any subsequent launch), this error is likely to indicate that the stored database credentials are incorrect in some way. Talk to your IT Team about ensuring you have the right server / port / login credentials, and consider resetting the application config (see the FAQ's Section "ASSIST-CKD Version 4") if you find you have the wrong details

When there is a lot of data in the database, the application can slow down significantly on the Analyse or Graph screens. After some time, a pop-up will show explaining some possible reasons for this, including a link back to the Application Dashboard in case you want to stop the load. The best resolution to this would be to use the filters on the Analyse screen - especially the date fields - to reduce the number of patients returned by the query. If the problem persists despite small patient sets or limited data in the database, you can ask your IT Team about rebuilding the indexes on the ckd_gfr table. This has worked to solve many performance problems during initial deployment and development. It is recommended that Database Administrators setup routine maintenance including the index rebuild on the ckd_gfr table so as to minimise this problem for future usage. Occasionally, this problem can be caused by slow or congested networks; in which case trying again later may improve overall performance. If all solutions have been attempted and the problem persists, try leaving the application on the slow load warning for up to an hour. If the load does not complete, get in touch with the support team with details about what you were trying to do when the slow load occurred.

This can occur either during installation (while the “Installing” progress splash is shown on-screen), or during application setup. Usually, this is down to directory and user permissions and/or anti-virus or firewall installations. To resolve this error it is recommended to speak to your IT Team and/or local administrator; running the installer .exe as administrator often solves the issue.

In some circumstances it can be useful to reset the application to “factory settings”, effectively undoing any configuration including application settings, database connection details and email server details.

To reset the config, simply delete the contents of the Config Directory (see "where is the application installed?").

Note that the Config Directory also contains the application’s activity/error logs - you may wish to retain these specific files across a config reset by making backups of them.

Note that if you selected the wrong database type on initial setup, or you need to change your database connection details for any reason, a config reset will be necessary.

The application has two key directories after installation - the installation directory (where the application itself resides) and the config directory (the location of error logs, application settings, and upload error details).

Installation: C:\Users\{your-username}\AppData\Local\AssistCKD Config: C:\Users\{your-username}\AppData\Roaming\AssistCKD

The main configuration files, storing your database and email server connection details, are located in the config directory: [config-directory]\assist-ckd-config.json and [config-directory]\assist-ckd-email-config-email.json

The application creates a log of all its activities at the following location:

C:\Users\{your-username}\AppData\Roaming\AssistCKD\log.log

If you encounter a critical error (application freezes, error message box pops up, or other unexpected / blocking behaviour), most commonly the log will contain information about what went wrong. It is recommended to either open a support ticket at https://assist-ckd.org or email support@assist-ckd.org with your log file attached, as well as a description of the problem you encountered and any screenshots you can gather surrounding it.

Please note: the log file will contain copies of all data you upload to the database, which will include confidential patient data. It is vital that you modify the file to remove this data before sending it to the support team.

Sometimes the application will need to skip some data within a given file due to one or more fields being invalid. If this occurs, you will receive a non-blocking error once upload has completed, detailing how many rows were skipped.

Information about these skipped rows can be found by clicking the link to the file provided; situated here:

C:\Users\{your-username}\AppData\Roaming\AssistCKD\errors.csv

In these cases, data must be modified to fit the schema of the target table and re-uploaded, if you don’t want to skip the rows and leave them out.

See the FAQ's section "Common Error Messages" for more information.

The application does not perform any encryption of patient data.  It is up to the individual Trusts to ensure that the way the patient records are stored is compliant. If using SQLIte as a storage mechanism it is recommend that the hard drive the database file is installed on is encrypted. The application will restrict sending emails to addresses that end with valid NHS extensions. It is the Trust IT department's responsibility to ensure that emails are sent securely end-to-end.

For testing and verification, we recommend using the application’s “SQLite” database option for quick independent setup. The application comes with some valid eGFR Control Data to facilitate the testing of basic upload and analysis functionality within your site. This can be found at the following location, after installation:

C:\Users\{your-username}\AppData\Local\AssistCKD\app-{version}\resources\app\docs\ckdtest-valid-gfr.csv There is also a file named "ckdtest-valid-gfr-large.csv" at the same location, to use for testing large uploads which may take longer and incur a higher risk of errors.

1) Installing the application. Your IT department will need to install the application on the reviewers’ devices if your user doesn't have permission to install the applications. The application requires a database server. It is up to the individual trusts to determine which database server technology is most appropriate for your installation. The options are SQLite, Mysql or SQLServer 2008+. 2) Extracting/Importing data from the LIMS systems There are two ways by which to import data into the ASSIST-CKD software. Either directly into the database (if using SQLServer/MySQL) , or via a CSV export from the LIMS systems which can then be uploaded using the "LOAD DATA" functionality within the application. It's down to the individual trusts to decide on the preferred method for data transfer. ASSIST-CKD software supports the upload of .CSV files however we are aware of trusts who have automated this upload process. For example Kettering;

"We use our integration engine (Rhapsody) to pick up files from our Pathology system, which filters out the relevant Biochemistry results and feeds them into a new "CKD" route within Rhapsody. This new route picks out any results with an eGFR and then from those, picks out the useful information (e.g. report data and demographics), as well as bringing in any useful supporting information (e.g. practice details) from our patient master index, before using all this gathered data and writing that to the CKD tables (which bits it uses depends on whether it's inserting or updating tables).”

As an external body we are unable to advise on how to configure your LIMS system to automate this process. This is something you would need to request and resolve internally.

ASSIST-CKD is an intervention to improve the care of people with kidney disease.  It is based around a piece of software which enables laboratory staff (or other trained members of the healthcare team) to review patients eGFR test results in graphical form. This helps to assess trends in kidney function. When viewing each graph the reviewer decides whether the patient should be "marked". Marking a patient means that a report is sent to their GP highlighting the fact that their kidney function has deteriorated over time.

These tasks should be performed on a weekly basis

1. Run the enquiry to produce the weekly eGFR data extract from the laboratory LIMS. This step will not be necessary for those sites where this process is automated.
2. Login to the Graphing Software system.
3. Load data into SQL database as described in CKD User Guide.
4. Select the date from which to review the patient data – usually one week back from today’s date.
5. Select ‘other’ (GPs) and set the age range, one of which is for 65 and under with an eGFR cut-off of 50; the second is for over 65s with an eGFR of 40. It is possible to also select ‘outpatients’; however we recommend that this option is not used, as it will result in GPs being informed about tests that they did not request (and may not have a record of).
6. Once the list is generated, sort by location so all the practices are grouped together and then generate the graphs for review.
7. While reviewing the graphs, select ‘Inform Clinician’ for those patients whose eGFR is declining. The links to the screencasts below give advice on how to assess and review graphs.
8. The system records those patients who have already been flagged with their clinician. The results since that referral will inform the decision whether or not to inform the clinician again.
9. Repeat steps 5-8 for over 65s.
10. Once all the graphs have been reviewed, re-filter the graphs according to those that have been selected under ‘Inform Clinician’.
11. There are two further optional steps that are performed in Birmingham: a. Reviewthepathologysystemanddeterminewhetherthepatienthas had a repeat eGFR request since and if function has improved (however this is unlikely unless there’s been a delay reviewing the graphs). b. Determine whether the patient is under active review with a renal physician (this is likely to be difficult for most sites; an alternative is to amend the standard free text on the eGFR graph reports to reflect local practice. This is described in the CKD User Guide).
12. Delete the graphs of those who have been excluded if step 11 has been performed.
13. Print a list of those to be flagged with the clinician and file this list (paper and electronically) securely. A list of flagged patients needs to be sent securely to the UK Renal Registry at the end of each year.
14. Distribute the graphs of the flagged patients to the referring clinician. This can be done electronically via secure email, or by saving a copy of the graphs to the desktop and printing hard copies.

After the completion of local training in the use of the system, staff who are to conduct weekly reporting will be sent a batch of 30 anonymous graphs (together with a guide to interpreting eGFR graphs) and be required to report for each whether no further action is required or whether the patient is considered high risk and they would inform the requesting GP. Successful completion of this initial competency assessment is deemed mandatory before commencing live reporting. For ongoing external quality assessment, reporting staff will be assigned a unique user number and will be emailed 6 anonymous graphs and a mark sheet every 3 months upon which they will need to report whether no further action is required or whether the patient is high risk. Failure to participate will be brought to the attention of the local supervising consultant clinical/medical scientist with the recommendation that the staff member cease reporting. Failure to classify patients correctly will be followed up with the individual and further training will be offered. Failure to improve patient classification correctly will be brought to the attention of the local supervising consultant clinical scientist with the recommendation that the staff member cease reporting. Adjudication of patients as high risk or not will be made by at least two consultant clinical/medical scientists or nephrologists experienced in the process.

This will be dependent upon population size and the activities included within the laboratory. At HEFT (800,000 population), the Band 7 clinical scientist commitment is approximately 4 hours per week, with an additional 1 hour per week consultant clinical scientist supervision, 1 hour per week band 3 administration, and 0.25 hours per week ICT support. The time commitment will vary according to, for example, whether time to exclude known renal patients (as happens in the pilot site) is included, but we would not expect the hours spent (after initial run-in and training) to exceed those in Birmingham on a pro-rata by population basis. Additional time may be saved in those sites sending graphs electronically.

An understanding of CKD and the patterns and implications of eGFR. Computer literate. The model used at the Heart of England Foundation Trust (HEFT) is for graphs to be reviewed by a Band 7 Clinical Scientist on the HCPC register. Review by a renal nurse may be possible in some locations. Oversight and supervision is provided by a consultant Clinical (or Medical) Scientist. For sites where other models are proposed, these will be examined on a case-by-case basis by the project team; in all cases a period of formal training and directly observed working followed by sign-off by the local consultant Clinical (or Medical) Scientist lead will be required. This is not classed as a research project. We would therefore expect that graph review is carried out by service rather than research staff.

Step 1

An enquiry is run against the Laboratory Information Management System (LIMS) (eg Telepath, Winpath, Pathnet, Masterlab, Trak ) to extract the data items specified in the CKD Specification into a file (typically a .CSV file). For some sites this facility may be automated; for others this enquiry will have to be run manually on a weekly basis. At the project start an initial upload of historical eGFR data (ideally at least 5 years’) is performed.

Step 2

This file is then uploaded into an SQL database that has been previously setup either locally or on a central Trust IT server. For those sites that do not have SQL Server software (or no spare licensing capacity) a freeware MySQL version is also available. The SQL Server and MySQL database generating scripts have been made available free of charge by the project team. The upload functionality is built in to the latest version of the Graphing Software. The Graphing Software has been distributed free of charge; there is no licensing fee for the use of this software.

Step 3

The graphing software is run in the lab on a weekly basis. This is described in detail in the CKD User Guide. This step generates the graphs for review.

Step 4

An appropriately skilled and clinically trained member of staff reviews the graphs to decide what action is required.

Step 5

For those patients highlighted as high risk (the “Inform Clinician” group from the CKD User Guide), the graph is disseminated to the GP who requested the test. We would generally expect that the participating laboratories would communicate with their local GPs through the same medium (ie either physical/paper or electronic) as that which they would usually use to distribute results, although paper reports are acceptable if it is not possible to send electronically