The Data Protection and Digital Information (No. 2) Bill: its Impact on the adoption of Interoperability Standards in Healthcare IT and what it means for system suppliers

8-minute read

This blog discusses the UK Data Protection and Digital Information (DPDI) Bill and its implications for Interoperability Standards within the healthcare sector. If you are in the Healthcare IT market and operate in England and are unaware of this legislation going through Parliament, then you really need to know about it and what it means to your organisation. If you are aware of it and believe it is just another mechanism to mandate standards that will fail with no consequences, then you are in for a shock, because it isn’t.

Currently, the DPDI Bill is at the Committee Stage in the House of Lords, and its passage through Parliament has been delayed owing to the introduction of other emergency legislation. The Bill’s completion is expected before the Parliamentary recess in July. You need to start preparing now.

The Bill reforms the UK’s data protection framework. Recognising the importance of standardised data in healthcare, Clause 142 and Schedule 14 of the Bill (Information Standards for Health and Adult Social Care in England) of the Bill make changes to the Health and Social Care Act 2012.

The changes delivered by this Bill seek to establish information standards for health and adult social care services in England, particularly focusing on information technology (IT) and IT services. It provides powers for the Secretary of State to publish information standards, make technical amendments, and define terms related to IT providers and services. The legislation also enables the monitoring of compliance with these standards, with provisions for issuing notices to providers that are suspected of non-compliance with the mandated information standards. Furthermore, the Bill authorises the publication of statements by the Secretary of State that will set out that the IT provider has not complied with the information standards. Additionally, the Bill establishes a framework for accrediting IT and IT services, including setting criteria and procedures for accreditation.

The NHS and suppliers know that inadequate interoperability increases the cost of delivering care, reduces efficiency and diminishes patient safety, so mandating interoperability standard should be a good thing, surely?  The answer should be “Yes” but why have we not achieved the necessary improvements previously.?  What we have seen over the years is that it is not that straightforward.

Today, the standards and date by which compliance must be achieved are defined and published by the Data Alliance Partnership Board (DAPB). Achieving compliance on interoperability standards has been delegated to the Trusts to date. Whilst Trusts have been mandated to support these, most have found this incredibly challenging.  There are numerous reasons why, but the most common one is that the data required in the standard is held across multiple systems and it is difficult to get the data together, such as in the Transfer of Care standard.  As a result, suppliers have not invested, as their customers have not been able to use them. Suppliers are wary as:

• Using their finite development resource to build software to support these standards that aren’t then used by the NHS wastes valuable resource that could be used developing capability customers really need. If they do not believe there will be enough adoption then the decision whether to develop it is easy for them to make.
• These standards are just for the UK, or England, and international vendors might incur significant cost for a small part of their global (mainly US) business.  Within their overall requirements backlog, support for a UK standard might not be important enough relative to other items to prioritise it. 

Many will rightfully point out that the fragmentation of data across systems is because Trusts do not have a single system – an Electronic Patient Record (EPR) – in which data is stored, so frontline digitization is going to go along way solve this.  With more Trusts buying integrated EPRs data fragmentation will reduce.

The main interoperability standard being developed is HL7 FHIR UK Core from adapted from the HL7 FHIR international standard. UK Core takes the international FHIR Standard and makes it work for the UK. It is used with other standards such SNOMED-CT and DM+D which will inevitably also have parts of them mandated as a result of this Bill. Therefore, isn’t the quickest way to drive adoption of interoperability standards to mandate suppliers to support them – including UK Core? It certainly makes it easier for providers and provides the largest accelerator for the adoption of standards. Getting the top 10 vendors to support these standards should allow a very large number of provider originations to meet the standards. However, we are still left with the same problem. Unless the utilization by Trusts is massively increased, little progress will be made. We should also not forget that interoperability is not free, as suppliers must develop support for UK or even England-only standards. Let’s not even explore the notion that this can be solved by the NHS paying suppliers to develop the capability in their products. Although having risks, it would definitely give us a better chance of adopting standards, but it is something NHS England would never countenance.

There is more to it than that, though. NHS England has spoken a lot about their intention to co-produce standards with industry. This is something that industry would like to do, but today the work defining HL7 FHIR UK Core standards by NHS England has focussed on developing FHIR Profiles. What should this co-production mean? Is it the continuing development of FHIR Profiles, or would industry like something different? Well, suppliers want interoperability standards defined that have all material and information required to implement them. Today HL7 FHIR UK Core is very difficult to implement as there is no guidance, so perhaps the highest priority in this co-production should be defining the artefacts required to create implementable standards.

Once a standard has been mandated with a date by which it needs to be supported, there needs to a conformance process or certification that attests a supplier supporting that standard in one of their solutions. This sounds great in theory but many of us know, when NHS Digital ran this, the certification programme was a huge bottleneck. There are examples when a supplier, working with a Trust to implement a standard faced a queue that was so long, filled with other suppliers, it meant that it would take several months before they could certify. This has prevented suppliers conforming with standards as neither they nor their customer were prepared to wait. Mandating a standard will not solve this Previous experience shows that merely expecting suppliers to conform, without providing adequate support or guidance, does not facilitate adoption of mandated standards; in fact, it hinders it. However, NHS England intends to implement sanctions against suppliers who do not support these mandated standards, and there is suspicion that sanctions may become increasingly punitive over time.

There is a precedent for this. The CQC inspects trusts to assess that they meet certain standards in the operation of their organisation. Trusts are categorised as “Inadequate”, “Requires Improvement”, “Good” or “Outstanding”.

The DPDI Bill mandates creation of operators that will be responsible for establishment and operation of a scheme for the accreditation of IT and IT services used in health care or adult social care. This should mean there is greater capacity in the accreditation scheme than existed with NHS Digital. Suppliers could be required to support a standard and if they are suspected to not be compliant with the standard, they will be asked to comply within a specified period, or a statement could be published, detailing their non-compliance. This is huge change for Suppliers, and you need to be ready.

Mandating standards is a huge focus of NHS England to drive adoption, but there appears to be little consideration given to crafting specifications that are readily implementable. Rather than having so much ‘stick’ to get suppliers to conform, a more balanced approach, incorporating incentives, or ‘carrots,’ is essential. To achieve this, NHS England need to take proactive steps and must urgently define an HL7 FHIR UK Core Adoption Method. This is covered in my second blog.

Mandating Standards or making them easier to adopt?

A process to mandate standards to drive their use is not the only lens through which we achieve conformance. To be successful, we should consider conformance as a process to drive adoption by suppliers. Therefore, what we urgently need is a UK Core Adoption Method as we want to minimize time to peak adoption across the service, thereby decreasing the need for an enforcement process. It is possible to identify 5 things to be included in a UK Core Adoption Method which, in fact, would be required by suppliers to support standards that are mandated:

1. The supplier community, the Integrated Care Boards (ICBs) and Providers want standards that make it easier to achieve what they want to do. Standards that make it easier to do their work do not need to be mandated. As my colleague, Dunmail Hodkinson from HL7 UK asked “Was it difficult to get adoption of HTTP?” to which I’d go further back and ask the same about J2EE, and there are others. We need to ensure that the interoperability standards specified first are those that solve the biggest problems faced by both the ICBs and Suppliers. Furthermore, suppliers can often see the common problems and requirements across multiple ICBs that means they can confirm the most common problems that need solving. This is one of the main reasons why HL7 UK are working on UK Core Access API, to make it easier for suppliers to meet a large set of common requirements across ICBs and Providers.  This requires far less mandating, so UK Core Access API is surely a great example to set?
2. For any set of standards we are going to use, the contents of the specification need to be agreed. The specification needs to be implementable and today what we have is not something that developers could use to solve the intended problem it sets out to, or, just as importantly, to solve different problems. As a priority we need to define what should be in an implementable specification, and when we do, it will also allow any new specification defined locally to also be easily adopted by others. Another great way of driving adoption. A clear conformance specification reaps many other benefits, not only making it easier for suppliers to demonstrate conformance with a standard, but they are also testable so can be included in contracts.
3. Far stronger mutual trust needs to be developed between NHS England and suppliers. It is only by working more closely together can this trust be nurtured. For example, suppliers need to be able to directly see the backlog of interoperability requirements being curated by the backlog management function (today NHS England). Whilst the backlog defines what interoperability specification could be developed next, what suppliers need is looking from the opposite direction, what they expect to have to develop. Not only does this create a culture of no surprises, but it gives suppliers the confidence to manage their finite development resource to work on things they expect to have to do – even when it is rework of an existing standard on the backlog. This again will drive adoption more quickly.
4. Certification and assessment of suppliers’ solutions carried out by NHS England needs to have the required capacity as again this will drive adoption. To increase the capacity and to be able to scale it as and when needed NHS England needs to appoint partners who can do certification and assessment. Without this, the bottleneck will snuff out adoption.
5. Finally, thinking that a standard will be defined for a specific clinical workflow does not reflect clinical reality. Instead, 2 types of specification need to be developed.
   1. Generic architecture patterns and capabilities – such as access or transfer of care;
   2. Programme specific specifications for work in domains or such as, Maternity, immunization programmes, Child Health, etc.

Programme specific specifications should fit with the generic patterns and be developed against these general capabilities. Having this generic or more conceptual model or specification gives us re-usable pattern that can be used across multiple programmes. This again makes it an accelerator for the adoption of HL7 FHIR UK Core.

It is recognised within NHS England that the FHIR UK Core work to date does not have capabilities that are widely implementable or drive the adoption of UK Core. No generic architecture patterns and capabilities are being defined so making these more implementable is a priority.

Ominously for the enforcement of standards, even with the implementation of EPRs as part of frontline digitization, EPRs will not replace all systems in Trusts and there will be data in legacy systems that will never support UK Core. The issues of data fragmentation in Trusts are not going to go away completely and those same issues will persist and create obstacles for adopting standards. We will need different strategies to address this.

So, whilst we must accept there is a process of mandating coming, we should all be focusing on an adoption process that reduces the potential for sanctions being applied to suppliers for supporting standards that trusts may not actually use.

Much of the content of this blog results from conversations with CIOs, the NHS England Team, and the supplier community. Much of the thinking on adoption has been done by techUK, HL7 UK and the PRSB. This series of blogs is a collaboration between the same parties who need to make mandating and adoption successful. That’s a pretty good start, but this must be spread more widely as organizations need to be prepared and play their part in shaping its development and adoption.

I would welcome any comments and feedback on this blog.