Introduction to DCB 0129/0160

Hi and welcome to Safehand. My name’s Adrian Stavert-Dobson and I’m an independent consultant in health IT safety and regulation.

If your organisation manufactures or implements health IT systems, you’ll need to comply with the UK’s mandatory Standards and Regulations. Here at Safehand, it’s our job to help organisations to do that.

To shed some light on this topic, we’ve put together a few short videos to explain what’s involved. You can see all of videos in the members area of our website

In this video I’m going to go back to basics, and talk about a couple of areas of compliance. We’ll start with DCB 0129 and DCB 0160.

Research has shown that health information systems can have a significant positive impact on patient safety. They help us to prescribe medications safely, give us instant access to results and tells us when patients have important allergies we need to be aware of.

But we also know that health IT can sometimes introduce clinical risk. What’s more, the kinds of hazards encountered are often new and unfamiliar. Problems can arise in at least two different ways; they might be due to the way the product has been manufactured or the way in which it’s been implemented by the healthcare organisation. Both are equally important.

We all have a responsibility to make sure that hazards are identified and properly managed. NHS Digital have mandated two standards which explain how we should do this. If you’re working with any health IT product which could conceivably cause harm to a patient, then you’ll be required to comply.

The two Standards are called DCB 0129 and DCB 0160. But the Standards change their name fairly often, so its quite possible they might even be called something else by the time you watch this video.

Now the two Standards are almost identical in terms of their requirements. The difference is that DCB 0129 applies to the product manufacturer whilst DCB 0160 applies to the healthcare organisation.

The basic premise is that the manufacturer undertakes a piece of risk management work and records the outcome in a set of documents. These documents are passed to the healthcare organisation who build on them, and produce their own set of documents. The more collaborative the exercise the better. In fact, safety is a great way to get clinicians and technical staff to engage with each other.

But it’s very easy to get caught up in all the documentation. Remember that clinical risk management isn’t about writing reports, it’s ultimately about reducing risk. You can easily convince yourself you’ve made the product safe, when actually all you’ve done is write about it.

The earlier you begin safety work the better, as this gives you the chance to identify potential hazards up-front. You can then design and configure the system in such a way that those hazards are mitigated. We know from experience that it’s far easier and more cost-effective to build a safe system from the start than to try and make it safe later.

DCB 129 and 160 are a little unusual in that the person who does the work needs to have certain skills and qualifications. This person is called the Clinical Safety Officer or CSO. They have to be a clinician and be specially trained in this type of risk management. At Safehand, we have a team of people who act in this capacity for dozens of different organisations. You might want to talk to us about how we could do this for you.

Now, let’s bust a myth before we go any further. It’s important to realise that, in the UK, safety management is very  different from Information Governance, Security and Privacy. IG is dealt with by frameworks like the Data Security and Protection Toolkit and GDPR. So, just because you’ve done a DSPT submission and perhaps got ISO 27001 accreditation, doesn’t mean that you also comply with DCB 129 and 160. The two things are quite separate.

Let’s turn now to another area of compliance. Some health IT products will also need to comply with a different framework called the Medical Device Regulation. Now, a lot of digital health solutions aren’t Medical Devices. But, for those which are, if you fail to comply with the Regulation, then you’re potentially committing a criminal offence.

Medical Devices display a CE Mark to indicate that they comply – but gaining that CE Mark is no small undertaking. Depending on the class of medical device, it can involve putting a Quality Management System in place, implementing rigorous validation procedures, constructing a technical file and potentially performing clinical trials.

Deciding whether or not your software product could be a Medical Device can be very complex and the guidance produced by the regulatory authorities often lags behind the technology itself. Sometimes it’s easier just to talk things over. So, if you need help in this area, or want to know more about how we can help you with compliance, then go to the Contact Us section of our website.

There are further videos at the Safehand website where we talk more about health software compliance.