Skip to main content

Community Services Data Set (CSDS) v1.5

Community Services Data Set (CSDS) v1.5 is an uplift to the established CSDS v1.0 and is required to keep the data set relevant with current clinical practices, maintain compliance with national data standards, meet policy requirements and allow further submission of data for patients of all ages.

There are a number of small structural changes in this release, but their introduction will have a minimal burden on the care provider or system supplier organisations.

You can learn read about the full list of changes to the dataset by reading the DCB 1069 community services data set information standards.  


Technical Output Specification (TOS) v1.5 published 27 July 2020

This Technical Output Specification splits the data set into a number of groups, with each table containing data items and values.

Validations and derivations that will be applied to the data, on submission to the submission portal are also listed.

Data model v1.5 published 27 September 2019

The data model shows how the different groups of data within the data set are linked, using primary and foreign keys to join the records.

Please note, you might wish to zoom the PDF to a higher size to view the model in detail.

User guidance published 3 August 2020

 The user guidance is about what data should be included and how to map to and submit each individual data items.  

How to submit data via SDCS Cloud

The CSDS is changing its submission platform, from the Bureau Service Portal (BSP) to the Strategic Data Collection Service (SDCS Cloud), for version 1.5.

For information and guidance on the SDCS Cloud, including how to register for a user account and guidance on submitting data, please see the Strategic Data Collection Service (SDCS)  

In July 2020, we hosted a webinar which included a demonstration of SDCS Cloud and a general Q&A session on the go-live. Here’s a recording of the webinar:

View a transcript of this webinar recording

Welcome to this webinar where we are going to be talking about, and demonstrating, SDCS Cloud, which is the new service for submitting CSDS data to NHS Digital.

My name is Paul Arrowsmith, and I am the Delivery Manager for Data Processing
Services. There are two main services involved in data submissions to NHS Digital – SDCS Cloud itself, which is the front door of the service, and the thing that you will have access to as data submitters, and then the downstream Data Processing Services, which ultimately churn out the publications and the data extracts.

As an organisation we have two teams delivering each of these components. As I say, I am the Delivery Manager for the Data Processing Services, and we also have two people from the SDCS Cloud Team involved in this webinar – Samadrita Malik, who will be giving us a demonstration in a little while, and the SDCS Cloud Product Owner, Maria Timson.

In terms of raising questions, feel free to raise questions throughout. We would prefer to receive your questions, and any comments you may have, via the chat facility in Microsoft Teams. Please feel free to post your comments and questions there and we will pick those up in the second half of the webinar.

In terms of structure for the event, I am going to spend the first 10/15 minutes or so, giving you an overview of our delivery, how we have got to this point, and also calling out a couple of actions we need from you in the run-up to go live. Sam will then give us a demonstration of SDCS Cloud, and that should leave us with about 30 minutes to go through any questions you might have, which hopefully should be plenty of time. 

I should also point out that we have another couple of people on the call, Gavin Harrison from the Data Set Development Service, and Paul Rees-Walker the Product Owner on Data Processing Services. So, between us, we should be able to answer any questions that you may have.

Looking at the timeline for the delivery, firstly I will point out the colour coding. Anything in blue relates to the new service and the onboarding of version 1.5, the dataset onto SDCS Cloud. Yellow for the legacy system and remaining activity on the version 1.0 data set on BSP, and then the items in grey here, are the preparation work that we have been doing getting ready for onboarding version 1.5.

Going back to Autumn 2019, that is when version 1.5 ISN was published, and since then it has all been about the preparation. The key activities I have called out here, in terms of preparing for SDCS Cloud, are really about risk mitigation. Some of you may have been involved in the onboarding of mental health or maternity data sets to SDCS Cloud last year, and you will be aware that there were some issues around those deliveries, so we have tried to address those with the CSDS dataset. 

At the beginning of March 2020, we migrated all active users from BSP automatically, so that cohort of users did not need to go through the manual registration process. We then ran two phases of Private beta – one at the end of March, and then again between the 13th of May and the 9th of June. Obviously, you will be aware that we were originally on a path to go live on the 1st of May, but because of the Covid-19 situation, the decision was taken to extend BSP for a further three months. It was this decision really that gave us the opportunity to run that second phase of Private beta, which gave us some valuable learning which I will come onto later.

Looking at the timeline for data submissions, the BSP submissions have obviously being going on continuously each month throughout this timeline, but the last BSP submission window will open on the 13th of August, for the June Refresh data, and then will close on the 31st of August. In parallel with that, we had the first submission window on SDCS Cloud opening on the 1st of August, for July Primary data, and closing on the 31st of August. Then finally on the 1st of September, we are operating purely in an SDCS Cloud world, with the submission window opening for July Refresh and August Primary. If you would like to see other submission dates, these can be found on the CSDS pages on our website.

I am going to move on now and look specifically at registration issues. This webinar, or at least a version of it, was first delivered on the 28th of February, and some of you may well have dialled into that call. Following on from that, we automatically migrated 107 active users from BSP onto SDCS Cloud. You are going to see in Sam's demo that the use of SDCS Cloud is dependent on 2-factor authentication to verify the user's identity. The message in that first webinar was
really targeted at those 107 users to encourage them to log on to SDCS and complete their 2-factor authentication setup, so that any issues were resolved ahead of go live.

As of the 16th of April, we were in a good place. 53% of those users had done that setup; so over half of the people had gone through registration and were ready for go live. With the three-month extension, and the flurry of activity around the Private beta, we put this registration work on hold for a while, but we are now picking it up as we head towards the 1st of August. Since the migration in March, we have also had 29 new users that have followed the manual registration process. And once Private beta had closed, they have now been added to the SDCS Cloud user base. So now we have got about 80 users that still need to complete their registration, from those original 107, plus the new 29. There are around 80 users that now need to complete the registration. The action at the bottom of the screen there is to that group of users. We really need you to log onto SDCS Cloud as soon as possible. Sort out your 2-factor authentication setup, and by following that process we avoid any registration issues during go live. This is something that hit us hard during the onboarding of the mental health and maternity data sets, so I cannot stress enough the importance of completing this action.

I am going to move on now, and just give you a flavour of what happened in the CSDS Private beta. As you can see, we had 10 sites involved, although the 10th one was added to the process late in the day, so it was not quite as successful as the other sites. There is a little bit of sensitivity here because I have put the sites in order of how successful they were in eliminating or reducing the DQ errors. I have anonymized the names of the sites involved. The main thing I wanted to get across here is the number of times the sites had to submit data. I should point out, that these numbers here were over the course of phase one and phase two of the Private beta. The final three columns over here show the statistics for the final, and generally the best, submission.

In terms of the colour coding, you have got two sites here that were in green. That means they were completely clear submissions. The files were accepted into the downstream processing, and they did not have any record level rejections at all. They did have some warnings, and the percentages show the number of records that had a warning against them, so that starts to give you some indication of the number of DQ issues. The ones in amber, or the orange colour, again, they all managed to get their files accepted, but they did have some degree of record level rejections for one reason or another. And then the pilot site is in red, because they had some file level rejections that stopped their larger file from being submitted. They were able to get a successful file, but it was only with 10 records. OK, so that is a very high-level overview. 

In terms of the findings from the Private beta. First of all, it is worth noting that the submissions in the Private beta were based purely on data from November 2019, so the idea was that we would compare the publication measures from the Private beta with those presented in the actual November publication from BSP. Overall, we found a pretty good match between the publication and the Private beta measures, which gives us confidence that we are in a strong position for go live. As I said earlier, it took a significant number of submissions with the Private beta sites, working iteratively, to eliminate DQ errors. The SDCS Cloud Service itself provides DQ reports back to users, but they do have a different format from those provided by BSP, and we realised during the Private beta that the sites were sometimes struggling to understand how to use those reports. We have taken that learning and used it to produce a guidance document which is almost ready for publication and should appear on our website in the next few days. We are also planning a second webinar to focus in on those DQ issues and provide an overview of the DQ guidance document. We have just been discussing that webinar actually. We think it is going to be scheduled at 11 o'clock next Friday, on the 17th of July, but we will be sending out communications to formalise that in due course.

So just to round this off, the second action I want you to take from this is to recognise the issues experienced by the Private beta sites. Try and make time to attend that webinar and review the guidance once it becomes available.  And critically, please try and submit data as soon as possible after the 1st of August, to give yourself enough time to work on your DQ over the course of that first submission window. OK, so that is it from me. I am going to take a breather now and handover to Sam for the demo. Over to you Sam. 

Thank you, Paul. Good morning everyone. Welcome everyone to this webinar of CSDS data set on the SDCS portal. I will just start with the basics, like after the action that you received, your email address has been registered with the SDCS Cloud application and you will also receive your password. If you run into any kind of issue, there is a link to Self Service to reset your password. I will just check that this is a new user, who has got the credentials. When they click, they will be asked to setup the 2-factor authentication, which is very easy. You can either choose a mobile application to store your One Time Password (OTP), or you can have an extension like I have now in the browser itself, if it is a private machine. I think that is sometimes easier if you forget your mobile or anything else.

Let us start with this one. Basically, go there, add it, and it says it has been added. This is the one I have added. And there you go; you will be presented with the home screen of the SDCS Cloud application. You get two links, one is to 'Submit a file', and the other one is the 'Dashboards'. If you click on 'Submit a file', you will see an error. If your RBAC, and the organisations you are submitting for, or your role has not been added properly, the user will see this. Let us move on to another user, who already has been setup. I already have that user setup; I will just need to find that user. When you have setup your OTP, the next time you try to log in, it will ask for your authentication code.  You can always see the 'Home' screen, which is the same. Or you can go from the top one, you can go to the 'Submit a file' screen. And these will be your roles, which have been setup. 

I will start with 'Organisation' a test organisation, this one has the CSDS role added to this user, to submit the data for this organisation. All the organisations you can see, if you are submitting for multiple organisations, will be listed here in this dropdown box. You might be submitting for one organisation for the data set, or another one, you might be submitting multiple data sets for this organisation. Currently CSDS data set does not have any active submission windows, so it will all be greyed out, and you will not be able to submit against it when there is no active submission window open for that particular data set.

I will start with a mental health one, which we have an active submission window for. The next dropdown box is to submit; select the submission period for which you want to submit the data for, I will pick June, this is your file, then you will get the 'Uploading' screen depicting the file. A user can also go to 'Dashboards' and see the previous 'Submissions' they have made for those organisations. There is a 'Filter Submissions' in which you can filter, as per whichever data set you want to check. If I select a particular organisation, you can also select by the status of the submissions. You will see which of the submissions you have made, they will all be there. You can clear the filter, and it will show you all the submissions previously made by the user. Also, if you have the Analyst role assigned to yourself, then you will also be seeing the submissions made by the other users, or other submitters, for the same data set, for the same organisation.

The file has gone into 'Processing' state. You can now either go back to the 'Dashboards', which I already have open in another tab, or you can also go and 'Submit a file'. So, go back to the screen and you can start submitting. You can
also see the status of the file which you have uploaded here, and the submission status for the previous files submitted here. Once it has gone through, you will be able to see that file. If you click on the 'View' column, it will take you to the 'Submission Summary' page, where you will be able to see all the counts. The file you have submitted, the submitter for that file, the 'Available Extracts' section gives you the ability to download all the Summary Reports, and the Pre-Deadline extracts available. If the Post-Deadline for that period is available, you will also see another Pre-Deadline. Let us see if I have any.

On the submission page, you can see we have the 'Test Submission' functionality there, which will only be active if you have an active submission period. If I do MSDS and click this button checkbox that Submission will be a 'Test Submission', then again go to make a submission there. In the dashboard, you might have noticed the slight difference in the colour of these, the more greyish are the test submissions that the user has made. Just to differentiate between a non-test and a test submission. If anybody has anything to ask, please write it down in the chat, and we will get back to those questions. Thank you.

OK. Brilliant, thanks for that Sam. So, the rest of the session really is open now to questions that have come through the chat facility. I have been having a look at those whilst Sam's been presenting, and it does look like some of them have been addressed by some of the people on the call. Many thanks for that. I will work through them just to make sure we have not missed anything. 

The first question is a question on the data sets linked to your SDCS Cloud account. “I used to have CSDS and IAPT, and MHSDS, but now only seem to have CSDS and IAPT. How do I get MHSDS reinstated? Do I need to register as a new submitter for MHSDS, as I don't do submitting very often?” My initial reaction is, it is a bit odd that you suddenly lost MHSDS, unless there is a time limit, in which case it gets disabled – that is a possibility, but the basic response is going to be one of raising a call with the National Service Desk to get this one resolved. 

Sam: I think Paul you are correct in saying that there is no timescale as such that automatically a user will be disabled after a certain time, but we do have Service Management and other teams, always managing those things. If they have received a request previously to disable that user for that data set, then they might have done it. If not, it is very easy, just raise a call with the National Service Desk, and they will be happy to investigate. 

Next question: "What do you do if your account has been linked to a different Trust?" Not quite sure how that has happened. It possibly could be as a result of the automated migration, if you were linked to a different Trust on BSP, or maybe there was a change of Trust and so there could be other reasons obviously, but the fundamental thing is if you are allocated to a different Trust, then get the Service Desk call raised, and get that one sorted out.

Comment: "This looks really complicated!" That is a little bit worrying that you have said that. That was at the beginning of Sam's presentation, so hopefully that opinion changed as the conversation went on. If not, please raise further questions. If you need any further clarity from us or follow-up offline, that is fine, but hopefully the situation has improved for yourself.

Next question: "Can we submit a test file now, please?" Right, OK, so some of you have commented further down as well that there is a test submission facility that has appeared recently. This is a recent development from the SDCS Cloud team, we are trying to work through how to get that into live operation, because we have got to make sure it can be handled correctly by the downstream processing. We are working through that now, and hopefully get that available to you as a live service for CSDS submitters. It is on its way, and it is something that we are working on right now. Maria or Sam, I do not know if there is anything you want to add from your perspective there? Sam: Not really, I think it is the same. It is a very new feature that has gone live, which was I think a long-awaited demand from all the submission providers. But fortunately, we were able to deliver it a couple of weeks ago. I think submitters did want it this feature going forward. 

Next question: "Would it be possible for the months to be in chronological order in the dropdown list, rather than in alphabetical order?" I do not know if we have had that question before Sam, if that is something that we are considering? Sam: Yeah, I think we Admins, while this was in development, we did raise this one, to be in chronological order. It makes things easier, but I think the sorting order in the back end works very differently; we tried a couple of times. The back end components that we are using, if there is an upgradation on that, then we will definitely take that into consideration and make it in a more chronological way, rather than an alphabetical way. OK, so that is something we are looking at, so that is good.

Next question: for CSUs, "How do we download the data from SDCS?" This is an interesting one, and this is very much in my camp, for my team. What is happening in terms of commissioning data is the same as what we did with mental health and maternity. We are building data extracts to go to the DSCROS and then the DSCROS will be responsible for sharing the data onto their local CCGs and CSUs. That is going to be the process moving forward, so hopefully that addresses that one.

Next question: "Can you re-link your authentication registration? Mine was setup to work on my office PC but I don't have access to that right now." This is really one for the SDCS Cloud team. Are you able to address that one Sam? I am assuming it is possible. Yeah, I think you just need to raise a Service Desk call, and the second line will be able to help individuals. It is not a major thing, it is minor work, so they will delete the old one and then the user will be able to reconfigure their OTP on the new device. OK, thank you.

Next question: "Is the required XML conversion tool still a 2010 Access database?" The conversion tool has now disappeared. I know there was a conversion tool required to submit data into BSP. That has disappeared completely now, and I think the discussion on this went on to talk about the XSD, the XML format, and the IDB access database format. There is an option with CSDS, but in both cases you just follow the schema that is defined for XML or the IDB, and the system just consumes that. There is no need for you to feed it through a conversion tool like you used to on BSP. So hopefully that addresses that one. Yes, so [an attendee] is confident in what I have just said. Just to be clear, you mean that we can just upload the IDB? Yes. Thank you. Yes, [an attendee in the Teams Chat] confirming the same there, confirming that the files are available on TRUD. Yes, and [another attendee in the Teams Chat] confirmed what I have just said, that you can submit XML file or an Access database.

Next question: "Are there any other RiO users in the group?" Some people have highlighted themselves as RiO users. 

Next question: "I wonder if two different email addresses were used for registration and hence not all the data sets were shown at once?" OK, so that is going back to the problem where one of the users had the MHSDS email. I am sorry, I might be going over a conversation that has already been resolved here, but I will carry on going through them.
Next question: "I submit MHSDS and I can see the CSDS dropdown, do I still need to register to submit?" Yeah, so this goes back to my bit in the presentation, where I did call out a specific action. It is really important that when you registered, whether it was through the automated migration or through the DUC form through the manual process, you should have received an email with your logon details. It is important that you take that to the next stage. You need to access SDCS Cloud and make sure you have setup your 2-factor authentication. Try to do that as soon as possible, and certainly ahead of go live, because we want to try and avoid any issues on that, when it gets to the go live day. 

Next question: "Open Exeter didn't manage to reset my colleagues’ passwords or create the new accounts quite in time for migration. Still struggling to get BSP access for them, despite requests from April. Will my colleagues’ need BSP accounts to be able to register for the Cloud?" No. They will need BSP accounts to carry out any submissions that you need to do through to the end of August, so they will need BSP accounts if you want them to do that. In terms of registering to SDCS Cloud, there is no other opportunity to do a migration from BSP, so it would not be of any benefit to create BSP accounts just to get onto the Cloud. The only mechanism to register on SDCS Cloud is via the process, so they must submit something called a DUC form. So again, probably over the course of this month of July, they need to get those submitted, and we can hopefully get you registered in time for go live. I hope that makes sense.

Next question: "It used to be very easy to spot the most recent successful submission as the role was coloured yellow. Will this still be the case?" How do we go about identifying more successful submissions in SDCS Cloud? Once you have submitted, at your submission screen it will give you the status of processing, and if it is successful, then in the dashboard, you will have the status of processed. With a status word of processed, it will be a view link available in the action column. So, you can view successful submissions in the records – all your extracts, everything, and it will also show you the process. The yellow bit? The submission has the role as coloured yellow. Not sure. It just highlights from the accessibility point that, for users, to make the application more accessible, for compliance we have used various colouring techniques, so when a user points, especially in IE11, even in Chrome as well, when you click, try to hover over a particular link, it will highlight the yellow colour. So even if it is rejected, or processed, it will still highlight. OK, thank you. OK, thanks Sam. 

Next question: "Has the process been improved for DQ reports? In SDCS Cloud once posting is complete it takes a while for DQ reports to appear." I am conscious of the comments that came through, particularly in the early days of MHSDS, and MSDS. And I believe that the teams have been working on improving that, and as I say, we have been focused very much on the content of the DQ reports, and making sure that we provided enough guidance so that users understand how to navigate those DQ reports. I have been less close to the performance issues. Sam, I do not know if there is anything you can update us on in terms of the performance? So, the portal works in conjunction with the processing as well. The processing team is different from the portal. Once we have the file, we land it, it goes through the processing where all the validations, derivations, and all the checks happen. it varies from a file size perspective; sometimes they are quicker, if it is a very small file, but medium and large files do take time, which is beyond the portal’s control. But I think, the core team and the processing team are working to enhance that performance. We have not received any kind of incidents recently depicting any performance issue. That is my understanding, that things have been improving steadily since we went live with mental health and maternity last summer. I think for my part, in my team, one of the things that we have got left to complete before we go live is non-functional testing, that is on-going. Obviously with CSDS, some of the files can be quite large, which means it could take longer to process those DQ reports. It is something that we are tracking closely as we go through that non-functional testing, and depending on the outputs, we will have the options to look at making optimisations to the processing ahead of go live. It is something we are focused on as we head towards the 1st of August.

Next question: "Can you please confirm the email address for when we need to raise a support call?" The National  Service Desk email address is If you have any further questions following today, if you can email that, we can take any further questions offline.
Next question: "Will the new upload tool work with link tables to SQL Server?" I do not know enough technically to answer that. We have tested both XML and IDB format submissions in the pilot sites, and we did not experience any problems. We did have file level rejections early on that they had to resolve, but as you saw in my summary slide earlier, all 10 sites were able to submit a file using the new SDCS Cloud facility.

Next question: "Would the data structure remain unchanged for download from DSCRO extract?" Well, that depends what the question is there. So, the download is obviously different from BSP because there are new tables in the data set. And for those that are closely involved in the DSCROS space, there has also been an agreement that the DSCROS will now get the full national download. So that is another change regarding that extract as well. I am not sure if that answers the question? If you want to ask a more specific question further down, I am happy to pick that up.

Comment: "I use an interim access database to pull data from our data warehouse via SQL this then populates the submission database. The submission database is available on TRUD." Yep, OK.

Next question: "A question for SDCS Cloud, when will the email notification for submission status be implemented?" Is that something you have in your pipeline? Unfortunately, it is not something that I am aware of currently, but I will take that offline because I will make sure it is considered as a possible future enhancement.

Next question: "Can you send out the DUCK forms for people in my team?" So, DUC does not have a 'K' on the end; it is a Data User Certificate (DUC) form. The DUC forms are received via the Service Management team, and they take it from there. The user raises it, and it comes to the Service Management team for registering and adding those users. The users need to raise a service call to get the DUC form, or can they download it from the website: - 

Next question: "Will one form need to be filled in per data set?" The answer is yes. 

Next question: "Will the extracts be supplied to CSU via MESH, and can you provide expectation data in line with provider submission via SDCS?" So, the commissioning extracts go to the seven DSCROS. If that is what you mean by that, then yes, they go to the DSCROS via MESH. If we are talking about the CSUs receiving the data beyond the DSCROS, then you will get them from the DSCROS directly. 

Next question: An attendee would like confirmation that "the June refresh will be submitted via Open Exeter and July Primary will be submitted via SDS Cloud." That is exactly right. The June refresh will be the last one on BSP between the 13th of August and the 31st of August. The July Primary will run for the whole of August.

Next question: asking if there are any EMIS users on the call? I suspect there will be because we had around about 100 people on the call, as far as I know. Some people are starting to identify themselves as EMIS users, so hopefully that will help.

I am going to keep the webinar going for a little while because I am conscious that people might still be thinking things through and may have some follow-up questions. I will keep it going for another few minutes. 

Next question: "On the SDCS Cloud 'Home' page there is a link to 'Contact Us' but there is no reference to SDCS on that page. Could it be added?" So, I guess that is one for you, Maria, and Sam to pick up. 

An attendee in the chat is questioning the submission window. The decision was taken to align the BSP windows with the SDCS Cloud window. So, the decision is being taken with the SDCS Cloud window still open from the 1st of the month all the way through the 31st of the month. It is more logical to align it with the start and end of the month. So, because the first SDCS Cloud window is closing on the 31st of August, the decision has been taken to align BSP with that as well, so that final BSP window will actually close on the 31st of August for the June refresh. 

Next question: “Is there any update on TPP SystmOne functionality being compliant with CSDS version 1.5?” I have not got any specific information on compliance of system suppliers. The experience we had with the 10 pilot sites, all those sites were able to get involved with the pilot, with the Private beta, without any direct contact with their system suppliers. They were able to access the back-end database of their systems and submit the data. I appreciate that might not be the case for everybody, but I think there were some TPP users in that camp. So hopefully you have had chance to get that resolved with TPP. Yes, and an attendee has added the link: -

Next question: "Can we get more details on what file type we are submitting, as I would normally use the XML converter, but you say this is becoming obsolete?" Yes, so the XML converter, if I get this right, you use that to submit an IDB file, and it converts it to XML format for the submission(?). It might be the other way around, but that is what you do. When we are saying it is becoming obsolete, whatever file format you create to feed into that conversion tool, just submit that in the version 1.5 format. Just submit that to SDCS Cloud, forget about the converter and follow the IDB or the XML format. That is on TRUD and submit that to SDCS Cloud. It should hopefully be a simpler process. Just take the converter out of the equation.
Gavin: Hi Paul, I can add a bit more to that, if it helps? It was always the case back in CSDS version 1, that you could submit an XML file, so you did not need to use the conversion tool by itself, but I know a lot of users did use the conversion tool to populate an access database. Then there was a process to use, and the access database created a separate XML file. In reality, everybody was submitting an XML file. When it comes to CSS version 1.5, that conversion tool is not being used, it is being replaced by a separate access database. But that does not have a conversion functionality. It is just a populated access database, that you can optionally submit. But for those who have the facility to generate an XML file some other way, then that is acceptable as well. I hope that answers the question. 

Next question: A follow-up question on the DSCRO extracts. "Are there any sample extracts that CSUs can download aligned to version 1.5, to confirm when we actually start receiving data in the new format?" So, the essential answer here is that there is not going to be an option to download files from SDCS Cloud. The only things that are available through SDCS Cloud back to providers, where they can receive the pre-deadline and post-deadline extracts as we saw in Sam's demo. Everything else comes from extracts from the downstream processing. From a commissioning point of view, that is encapsulated in the commissioning extract that goes out to the seven DSCROS, so the only avenue to CSUs is that data that is coming via the DSCROS. I think if there are any concerns around that, and any follow-up, then please come through to that data processing email address that was in the chat earlier, and we will pick that up directly with you.

Next question: "I still feel lessons have not been learnt from MHSDS migrating to SDCS. We are required to start submitting CSDS next month, and to date there is no testing? I still feel both submission platforms, BSP and SDCS, should run in parallel in DQ reports on SDCS..." Yeah, OK. I mean it is a fair challenge, and across NHS England, there are big concerns around the mental health and maternity experience. Have we learnt those lessons? We have tried to mitigate it as much as we can. The two things I tried to focus on in my presentation were around registrations. That is where we had a lot of problems with mental health. So, we are trying to make sure that we are sorting all of those out, to get rid of those kind of service questions that might hit us at go live. I appreciate your point on the testing generally, but we have tried to focus on this Private beta to make sure, from our side, that everything is working correctly ahead of go live. But also learning from the experience of those 10 sites, to understand what problems are specific to CSDS users. That is how we have tried to address those lessons that we experienced with mental health and maternity. We are trying to look at the test submissions, and if we can, we will get that working ahead of go live. But it does go back to that action that I said at the beginning as well, if we can just encourage users to submit data as soon as possible from the 1st of August, then at least you have got that full submission window to be submitting data, and effectively testing in that way. So that is where we are. We think we are in a good place with all the learnings from the Private beta, and hopefully that puts us in a good position, or a better position, than we were with mental health and maternity.

Problem here: "trying to download the Community Services Data Set (CSDS) Intermediate Database (IDB), but it doesn't look to be on the link." I think they need to make sure they are logged into TRUD and have subscribed to the items to get access to the download link. It is probably that that is the issue. 

Next question: "Do we need the converter to generate an XML file?" I think I answered that, but just to reiterate, it is an option. If your extract can produce an XML file, then you can submit that straight from your system, if it is compliant with the schema. If you have been used to using the conversion tool, then you will probably want to download the IDB, but you just need to populate that IDB, and submit that file itself. You do not need to do anything else.

Next question: "Regarding CSUs receiving data going forwards. Messages above state it will be sent via MESH. I normally download the data. Is there a contact email address that my colleagues’ can contact to allow them to setup the MESH side of things?" I do not know if that is one to us, or to the DSCRO potentially there? I think in terms of the MESH configuration, it is literally just the seven DSCROS that are going to receive that, and those seven DSCROS are configured for MESH, and already received the extracts from mental health and maternity. That is already in place, so I think there is no need for anybody else to setup MESH. I think there is some confusion here about the downloads, and the functionality. If you are expecting a download, and you are not a DSCRO, then you need to be speaking to the DSCROS to make sure you are getting what you need from them with CSDS. The same also applies to IAPT when that goes live a month later.

Next question: There was a question about is CDS going to the Cloud? I think that has been answered that in the chat. Not right now, but there is an upcoming minor version 6.3 release, but we will communicate further about that when that comes along. This is very much about CSDS is this webinar, and not CDS.

Next question: "We would like to test the process from our side before we need to use it formally. Especially as a new tool hits at the summer holidays." Yes, I think again, we will try and get that test facility up and running. All I would say is if we do not get that up and running for the 1st of August, there is still the option to test in effect. You can send multiple submissions in during that first submission window, between the 1st of August and the 31st of August. The only one that will be accepted into the downstream processing is your last submission. It is still possible to do a 'test' within that submission window. But as I say, we are doing our best to make sure that test facility is available pre-go live, and we will send out communications as soon as that is available. 

Next question:  "Will the items that cause it to error (such as a % symbol) no longer be an issue?" I do not know if that was a BSP problem that caused an error perhaps? I mean when I first read that, I thought it was in relation to those percentages I presented earlier. Was it something to do with the errors that we experienced during the Private beta? Now if it is in that vein, then they are not really an error that can be fixed as such. They have got to be fixed at a local level. Some of the pilot sites were still seeing some error codes, and it is because they needed to do more work on the DQ to get that fixed. No, that is not what was meant, obviously. They are talking about the access tool to strip out characters, so I do not know anything about that. I do not know if you know anything Gavin? Gavin: Maybe BSP used to not be able to accept a percentage symbol? It could be something to do with that, with special characters. Paul: I do not know if we have got any Developer on the call, who might be able to confirm that? It might be something we have to pick up offline. 

Last question: "How much have TPP been involved?" We have not had any direct involvement with TPP, but we have sent regular communications out to all systems suppliers, and we have had readiness questionnaire responses back, and I think TPP were one of the people that responded back. So there has been some communication with them. They are aware of the need to meet the standard, but as I said earlier, we were working directly with the sites when we were going through the Private beta. I think it is probably best that you make direct contact with your system suppliers, to make sure they are in a good position. 

OK, I am going to bring it to a close now, because we have overrun. Thanks very much. I really appreciate everybody taking the time out to attend this webinar. We will leave it there, so thanks very much everybody. We have noted all the relevant questions that we can answer; we will work on those and get back to you all. If there are any follow-up questions, please fire them through to the email address. Thank you everyone.

How to submit data to the CSDS

CSDS v1.5.1 XML Schema and optional Intermediate Database (IDB)

The CSDS is submitted to NHS Digital using an XML file that is compliant with the CSDS v1.5.1 XML Schema. The XML schema has been developed along with an CSDS Intermediate Database (IDB) tool that can be used as an alternative to the XML schema to enable providers to load or copy their data into the provided table structure for submission to the CSDS. To access the CSDS v1.5 XML Schema or IDB you will need to register and create an account through the link on the TRUD homepage.

Community Services Data Set XML Schema Version 1.5.1

The Community Services Data Set XML Schema Version 1.5.1 is available on the TRUD website from the NHS Data Model and Dictionary XML Schemas categories on the left of the page.

Intermediate Database (IDB)

The Community Services Data Set (CSDS) intermediate database tool for CSDS v1.5 is now available on the TRUD website and can be downloaded by clicking on the Data Set Development Services tools link on the left of the page.  

The intermediate database for CSDS v1.5 is a Microsoft access database and must be provided in this format. 

Last edited: 6 August 2020 12:48 pm